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!
