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 <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Tom Lendacky <[email protected]>
Cc: Michael Roth <[email protected]>
Cc: Haowen Bai <[email protected]>
Cc: Yang Yingliang <[email protected]>
Cc: Marc Orr <[email protected]>
Cc: David Rientjes <[email protected]>
Cc: Ashish Kalra <[email protected]>
Cc: [email protected]
Cc: [email protected]
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