Currently the ASP and SNP guest use an AES-GCM bases secure channel to communicate with each other. The IV for this encryption scheme is a sequence that each party maintains. Currently the ASP requires the sequence number of the request to be exactly one more than its saved sequence number and the ASP only increments its saved sequence number after a successful command. That means if the guest request ever fails it can only ever retry that exact encrypted command or discontinue its use of that VMPCK. If it were to try another command it would either need to reuse the sequence number which is the IC. That can lead to the encryption scheme failing with AES-GCM. Or if it incremented the sequence number the ASP would never accept the command due to sequence number mismatch. https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents/bcm/comments/800-38-series-drafts/gcm/joux_comments.pdf Cc: Dionna Glaze <dionnaglaze@xxxxxxxxxx> Cc: Borislav Petkov <bp@xxxxxxx> Cc: Tom Lendacky <thomas.lendacky@xxxxxxx> Cc: Michael Roth <michael.roth@xxxxxxx> Cc: Haowen Bai <baihaowen@xxxxxxxxx> Cc: Yang Yingliang <yangyingliang@xxxxxxxxxx> Cc: Marc Orr <marcorr@xxxxxxxxxx> Cc: David Rientjes <rientjes@xxxxxxxxxx> Cc: Ashish Kalra <Ashish.Kalra@xxxxxxx> Cc: linux-kernel@xxxxxxxxxxxxxxx Cc: kvm@xxxxxxxxxxxxxxx Peter Gonda (2): virt: sev: Prevent IV reuse in SNP guest driver virt: sev: Allow for retrying SNP extended requests arch/x86/include/asm/svm.h | 6 ++ arch/x86/kernel/sev.c | 28 ++++++-- drivers/virt/coco/sev-guest/sev-guest.c | 93 ++++++++++++++++--------- 3 files changed, 91 insertions(+), 36 deletions(-) -- 2.38.0.135.g90850a2211-goog
