aboutsummaryrefslogtreecommitdiff
path: root/lib/test_fortify/write_overflow-strncpy-src.c
diff options
context:
space:
mode:
authorBrijesh Singh <[email protected]>2024-05-01 03:51:56 -0500
committerPaolo Bonzini <[email protected]>2024-05-12 04:09:29 -0400
commitdee5a47cc7a45287ec1137edb745bb4dffbe85f6 (patch)
tree596d79d8d49bf723537c855cd50e4753a723b18c /lib/test_fortify/write_overflow-strncpy-src.c
parent136d8bc931c84fbe4c70c2d6e0a4d20a2aa90505 (diff)
KVM: SEV: Add KVM_SEV_SNP_LAUNCH_UPDATE command
A key aspect of a launching an SNP guest is initializing it with a known/measured payload which is then encrypted into guest memory as pre-validated private pages and then measured into the cryptographic launch context created with KVM_SEV_SNP_LAUNCH_START so that the guest can attest itself after booting. Since all private pages are provided by guest_memfd, make use of the kvm_gmem_populate() interface to handle this. The general flow is that guest_memfd will handle allocating the pages associated with the GPA ranges being initialized by each particular call of KVM_SEV_SNP_LAUNCH_UPDATE, copying data from userspace into those pages, and then the post_populate callback will do the work of setting the RMP entries for these pages to private and issuing the SNP firmware calls to encrypt/measure them. For more information see the SEV-SNP specification. Signed-off-by: Brijesh Singh <[email protected]> Co-developed-by: Michael Roth <[email protected]> Signed-off-by: Michael Roth <[email protected]> Signed-off-by: Ashish Kalra <[email protected]> Message-ID: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
Diffstat (limited to 'lib/test_fortify/write_overflow-strncpy-src.c')
0 files changed, 0 insertions, 0 deletions