For now at least, I want to keep with "KVM: SVM:" instead of using "KVM: SEV:". Many commits that touch SEV aren't strictly isolated to SEV, which means the "SEV" tag is unreliable. There's also the question of taggin SEV vs. SEV-ES vs. SEV-SNP. It's usually easy enough to squeeze SEV (or SEV-ES or SNP) into the shortlog, e.g.
KVM: SVM: Fix potential overflow in SEV's send|receive_update_data()
On Tue, Feb 07, 2023, Peter Gonda wrote:
KVM_SEV_SEND_UPDATE_DATA and KVM_SEV_RECEIVE_UPDATE_DATA have an integer overflow issue. Params.guest_len and offset are both 32bite wide, with a
"32 bits"
large params.guest_len the check to confirm a page boundary is not crossed can falsely pass:
/* Check if we are crossing the page boundary * offset = params.guest_uaddr & (PAGE_SIZE - 1); if ((params.guest_len + offset > PAGE_SIZE))Add an additional check to this conditional to confirm that
Eh, "to this conditional" is unnecessarily precise.
params.guest_len itself is not greater than PAGE_SIZE.
The current code is can only overflow with a params.guest_len of greater
"is can", though I vote to omit the "current code" part entirely, it should be obvious that this is talking about the pre-patched code.
than 0xfffff000. And the FW spec says these commands fail with lengths greater than 16KB. So this issue should not be a security concern
Slightly reworded, how about this for the "not a security concern" disclaimer?
Note, this isn't a security concern as overflow can happen if and only if params.guest_len is greater than 0xfffff000, and the FW spec says these commands fail with lengths greater than 16KB, i.e. the PSP will detect KVM's goof.
No need to send a v3, I'll fix up the changelog when applying. Holler if you disagree with anything though.
Thanks!