| Message ID | 20240421180122.1650812-22-michael.roth@amd.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support | expand |
On Sun, Apr 21, 2024, Michael Roth wrote: > These commands can be used to pause servicing of guest attestation > requests. This useful when updating the reported TCB or signing key with > commands such as SNP_SET_CONFIG/SNP_COMMIT/SNP_VLEK_LOAD, since they may > in turn require updates to userspace-supplied certificates, and if an > attestation request happens to be in-flight at the time those updates > are occurring there is potential for a guest to receive a certificate > blob that is out of sync with the effective signing key for the > attestation report. > > These interfaces also provide some versatility with how similar > firmware/certificate update activities can be handled in the future. Wait, IIUC, this is using the kernel to get two userspace components to not stomp over each other. Why is this the kernel's problem to solve?
On Wed, Apr 24, 2024 at 05:15:40PM -0700, Sean Christopherson wrote: > On Sun, Apr 21, 2024, Michael Roth wrote: > > These commands can be used to pause servicing of guest attestation > > requests. This useful when updating the reported TCB or signing key with > > commands such as SNP_SET_CONFIG/SNP_COMMIT/SNP_VLEK_LOAD, since they may > > in turn require updates to userspace-supplied certificates, and if an > > attestation request happens to be in-flight at the time those updates > > are occurring there is potential for a guest to receive a certificate > > blob that is out of sync with the effective signing key for the > > attestation report. > > > > These interfaces also provide some versatility with how similar > > firmware/certificate update activities can be handled in the future. > > Wait, IIUC, this is using the kernel to get two userspace components to not > stomp over each other. Why is this the kernel's problem to solve? It's not that they are stepping on each other, but that kernel and userspace need to coordinate on updating 2 components whose updates need to be atomic from a guest perspective. Take an update to VLEK key for instance: 1) management gets a new VLEK endorsement key from KDS along with associated certificate chain 2) management uses SNP_VLEK_LOAD to update key 3) management updates the certs at the path VMM will grab them from when the EXT_GUEST_REQUEST userspace exit is issued If an attestation request comes in after 2), but before 3), then the guest sees an attestation report signed with the new key, but still gets the old certificate. If you reverse the ordering: 1) management gets a new VLEK endorsement key from KDS along with associated certificate chain 2) management updates the certs at the path VMM will grab them from when the EXT_GUEST_REQUEST userspace exit is issued 3) management uses SNP_VLEK_LOAD to update key then an attestation request between 2) and 3) will result in the guest getting the new cert, but getting an attestation report signed with an old endorsement key. Providing a way to pause guest attestation requests prior to 2), and resume after 3), provides a straightforward way to make those updates atomic to the guest. -Mike
On Fri, Apr 26, 2024, Michael Roth wrote: > On Wed, Apr 24, 2024 at 05:15:40PM -0700, Sean Christopherson wrote: > > On Sun, Apr 21, 2024, Michael Roth wrote: > > > These commands can be used to pause servicing of guest attestation > > > requests. This useful when updating the reported TCB or signing key with > > > commands such as SNP_SET_CONFIG/SNP_COMMIT/SNP_VLEK_LOAD, since they may > > > in turn require updates to userspace-supplied certificates, and if an > > > attestation request happens to be in-flight at the time those updates > > > are occurring there is potential for a guest to receive a certificate > > > blob that is out of sync with the effective signing key for the > > > attestation report. > > > > > > These interfaces also provide some versatility with how similar > > > firmware/certificate update activities can be handled in the future. > > > > Wait, IIUC, this is using the kernel to get two userspace components to not > > stomp over each other. Why is this the kernel's problem to solve? > > It's not that they are stepping on each other, but that kernel and > userspace need to coordinate on updating 2 components whose updates need > to be atomic from a guest perspective. Take an update to VLEK key for > instance: > > 1) management gets a new VLEK endorsement key from KDS along with What is "management"? I assume its some userspace daemon? > associated certificate chain > 2) management uses SNP_VLEK_LOAD to update key > 3) management updates the certs at the path VMM will grab them > from when the EXT_GUEST_REQUEST userspace exit is issued > > If an attestation request comes in after 2), but before 3), then the > guest sees an attestation report signed with the new key, but still > gets the old certificate. > > If you reverse the ordering: > > 1) management gets a new VLEK endorsement key from KDS along with > associated certificate chain > 2) management updates the certs at the path VMM will grab them > from when the EXT_GUEST_REQUEST userspace exit is issued > 3) management uses SNP_VLEK_LOAD to update key > > then an attestation request between 2) and 3) will result in the guest > getting the new cert, but getting an attestation report signed with an old > endorsement key. > > Providing a way to pause guest attestation requests prior to 2), and > resume after 3), provides a straightforward way to make those updates > atomic to the guest. Assuming "management" is a userspace component, I still don't see why this requires kernel involvement. "management" can tell VMMs to pause attestation without having to bounce through the kernel. It doesn't even require a push model, e.g. wrap/redirect the certs with a file that has a "pause" flag and a sequence counter.
On Fri, Apr 26, 2024 at 12:57:08PM -0700, Sean Christopherson wrote: > On Fri, Apr 26, 2024, Michael Roth wrote: > > On Wed, Apr 24, 2024 at 05:15:40PM -0700, Sean Christopherson wrote: > > > On Sun, Apr 21, 2024, Michael Roth wrote: > > > > These commands can be used to pause servicing of guest attestation > > > > requests. This useful when updating the reported TCB or signing key with > > > > commands such as SNP_SET_CONFIG/SNP_COMMIT/SNP_VLEK_LOAD, since they may > > > > in turn require updates to userspace-supplied certificates, and if an > > > > attestation request happens to be in-flight at the time those updates > > > > are occurring there is potential for a guest to receive a certificate > > > > blob that is out of sync with the effective signing key for the > > > > attestation report. > > > > > > > > These interfaces also provide some versatility with how similar > > > > firmware/certificate update activities can be handled in the future. > > > > > > Wait, IIUC, this is using the kernel to get two userspace components to not > > > stomp over each other. Why is this the kernel's problem to solve? > > > > It's not that they are stepping on each other, but that kernel and > > userspace need to coordinate on updating 2 components whose updates need > > to be atomic from a guest perspective. Take an update to VLEK key for > > instance: > > > > 1) management gets a new VLEK endorsement key from KDS along with > > What is "management"? I assume its some userspace daemon? It could be a daemon depending on cloud provider, but the main example we have in mind is something more basic like virtee[1] being used to interactively perform an update at the command-line. E.g. you point it at the new VLEK, the new cert, and it will handle updating the certs at some known location and issuing the SNP_LOAD_VLEK command. With this interface, it can take the additional step of PAUSE'ing attestations before performing either update to keep the 2 actions in sync with the guest view. [1] https://github.com/virtee/snphost > > > associated certificate chain > > 2) management uses SNP_VLEK_LOAD to update key > > 3) management updates the certs at the path VMM will grab them > > from when the EXT_GUEST_REQUEST userspace exit is issued > > > > If an attestation request comes in after 2), but before 3), then the > > guest sees an attestation report signed with the new key, but still > > gets the old certificate. > > > > If you reverse the ordering: > > > > 1) management gets a new VLEK endorsement key from KDS along with > > associated certificate chain > > 2) management updates the certs at the path VMM will grab them > > from when the EXT_GUEST_REQUEST userspace exit is issued > > 3) management uses SNP_VLEK_LOAD to update key > > > > then an attestation request between 2) and 3) will result in the guest > > getting the new cert, but getting an attestation report signed with an old > > endorsement key. > > > > Providing a way to pause guest attestation requests prior to 2), and > > resume after 3), provides a straightforward way to make those updates > > atomic to the guest. > > Assuming "management" is a userspace component, I still don't see why this > requires kernel involvement. "management" can tell VMMs to pause attestation > without having to bounce through the kernel. It doesn't even require a push That would mean a tool like virtee above would need to issue kernel commands like SNP_LOAD_VLEK to handle key update, then implement some VMM-specific hook to pause servicing of EXT_GUEST_REQ (or whatever we end up calling it). QEMU could define events for this, and libvirt could implement them, and virtee could interact with libvirt to issue them in place of the PAUSE/RESUME approach here. But SNP libvirt support is a ways out, QEMU event mechanism for this will be a pain to use directly because you'd need some custom way to enumerate all guests, to issue them. But then maybe the provider doesn't even use QEMU and has to invent something else. Or they just decide to pause all guests before performing updates but that still a potential significant amount of downtime. > without having to bounce through the kernel. It doesn't even require a push > model, e.g. wrap/redirect the certs with a file that has a "pause" flag and a > sequence counter. We could do something like flag the certificate file itself, it does sounds less painful than the above. But what defines that spec? GHCB completely defines the current format of the certs blob, so if we wrap that in another layer we need to extend the GHCB or have something else be the authority on what that wrapper looks like and tools like virtee would need to be very selective about what VMMs it can claim to support based on what file format they support... it just seems like a significant and unecessary pain that every userspace implementation will need to go through to achieve the same basic functionality. With PAUSE/RESUME, tools like virtee can be completely VMM-agnostic, and more highly-integrated daemon-based approaches can still benefit from a common mechanism that doesn't require signficant coordination with VMM processes. For something as important and basic as updating endorsement keys while guests are running it seems worthwhile to expose this minimal level of control to userspace. -Mike
On Fri, Apr 26, 2024, Michael Roth wrote: > On Fri, Apr 26, 2024 at 12:57:08PM -0700, Sean Christopherson wrote: > > On Fri, Apr 26, 2024, Michael Roth wrote: > > What is "management"? I assume its some userspace daemon? > > It could be a daemon depending on cloud provider, but the main example > we have in mind is something more basic like virtee[1] being used to > interactively perform an update at the command-line. E.g. you point it > at the new VLEK, the new cert, and it will handle updating the certs at > some known location and issuing the SNP_LOAD_VLEK command. With this ^^^^^^^^^^^^^^^^^^^ > interface, it can take the additional step of PAUSE'ing attestations > before performing either update to keep the 2 actions in sync with the > guest view. ... > > without having to bounce through the kernel. It doesn't even require a push > > model, e.g. wrap/redirect the certs with a file that has a "pause" flag and a > > sequence counter. > > We could do something like flag the certificate file itself, it does > sounds less painful than the above. But what defines that spec? Whoever defines "some known location". And it doesn't need to be a file wrapper, e.g. put the cert in a directory along with a lock. Actually, IIUC, there doesn't even need to be a separate lock file. I know very little about userspace programming, but common sense and a quick search tells me that file locks are a solved problem. E.g. it took me ~5 minutes of Googling to come up with this, which AFAICT does exactly what you want. touch ~/vlek.cert ( flock -e 200 echo "Locked the cert, sleeping for 10 seconds" sleep 10 echo "Igor, it's alive!!!!!!" ) 200< vlek.cert touch ~/vlek.cert ( flock -s 201 echo "Got me a shared lock, no updates for you!" ) 201< vlek.cert
On Fri, Apr 26, 2024 at 05:10:10PM -0700, Sean Christopherson wrote: > On Fri, Apr 26, 2024, Michael Roth wrote: > > On Fri, Apr 26, 2024 at 12:57:08PM -0700, Sean Christopherson wrote: > > > On Fri, Apr 26, 2024, Michael Roth wrote: > > > What is "management"? I assume its some userspace daemon? > > > > It could be a daemon depending on cloud provider, but the main example > > we have in mind is something more basic like virtee[1] being used to > > interactively perform an update at the command-line. E.g. you point it > > at the new VLEK, the new cert, and it will handle updating the certs at > > some known location and issuing the SNP_LOAD_VLEK command. With this > ^^^^^^^^^^^^^^^^^^^ > > interface, it can take the additional step of PAUSE'ing attestations > > before performing either update to keep the 2 actions in sync with the > > guest view. > > ... > > > > without having to bounce through the kernel. It doesn't even require a push > > > model, e.g. wrap/redirect the certs with a file that has a "pause" flag and a > > > sequence counter. > > > > We could do something like flag the certificate file itself, it does > > sounds less painful than the above. But what defines that spec? > > Whoever defines "some known location". And it doesn't need to be a file wrapper, "some known location" is a necessary and simple parameter controlled by the cloud provider, so it's easy to make a tool like virtee aware of those what those parameters should be for any particular environment. But it's not easy to make it aware of a particular providers internal way of synchronizing guests and certs access. We'd be somewhat dependent of those providers either providing hooks to allow for better integration, which is "work" that might encourage them to just brew their own solutions, versus... Providing a simple reference scheme that's clearly defined, and easily adoptable across the board, which is "less work", and makes adoption of common tools/libraries SNP/certs/key management easier because we don't need to directly involve a provider's internal guest management mechanisms into those tools. > e.g. put the cert in a directory along with a lock. Actually, IIUC, there doesn't > even need to be a separate lock file. I know very little about userspace programming, > but common sense and a quick search tells me that file locks are a solved problem. > > E.g. it took me ~5 minutes of Googling to come up with this, which AFAICT does > exactly what you want. > > touch ~/vlek.cert > ( > flock -e 200 > echo "Locked the cert, sleeping for 10 seconds" > sleep 10 > echo "Igor, it's alive!!!!!!" > ) 200< vlek.cert > > touch ~/vlek.cert > ( > flock -s 201 > echo "Got me a shared lock, no updates for you!" > ) 201< vlek.cert > Hmm... I did completely miss this option. But I think there are still some issues here. IIUC you're suggesting (for example): "Management": a) writelock vlek.cert b) perform SNP_LOAD_VLEK and update vlek.cert contents c) unlock vlek.cert "QEMU": a) readlock vlek.cert b) copy cert into guest buffer c) unlock vlek.cert The issue is that after "QEMU" unlocks and return the cert to KVM we'll have: "KVM" a) return from EXT_GUEST_REQ exit to userspace b) issue the attestation report to firmware c) return the attestation report and cert to the guest Between a) and b), "Management" can complete another entire update, but the cert that it passes back to the guest will be stale relative to the key used to sign the attestation report. If we need to take more time to explore other options it's not absolutely necessary to have the kernel solve this now. But every userspace will need to solve it in some way so it seemed like it might be nice to have a simple reference implementation to start with. -Mike
On Fri, Apr 26, 2024, Michael Roth wrote: > On Fri, Apr 26, 2024 at 05:10:10PM -0700, Sean Christopherson wrote: > > e.g. put the cert in a directory along with a lock. Actually, IIUC, there doesn't > > even need to be a separate lock file. I know very little about userspace programming, > > but common sense and a quick search tells me that file locks are a solved problem. > > > > E.g. it took me ~5 minutes of Googling to come up with this, which AFAICT does > > exactly what you want. > > > > touch ~/vlek.cert > > ( > > flock -e 200 > > echo "Locked the cert, sleeping for 10 seconds" > > sleep 10 > > echo "Igor, it's alive!!!!!!" > > ) 200< vlek.cert > > > > touch ~/vlek.cert > > ( > > flock -s 201 > > echo "Got me a shared lock, no updates for you!" > > ) 201< vlek.cert > > > > Hmm... I did completely miss this option. But I think there are still some > issues here. IIUC you're suggesting (for example): > > "Management": > a) writelock vlek.cert > b) perform SNP_LOAD_VLEK and update vlek.cert contents > c) unlock vlek.cert > > "QEMU": > a) readlock vlek.cert > b) copy cert into guest buffer > c) unlock vlek.cert > > The issue is that after "QEMU" unlocks and return the cert to KVM we'll > have: > > "KVM" > a) return from EXT_GUEST_REQ exit to userspace > b) issue the attestation report to firmware > c) return the attestation report and cert to the guest > > Between a) and b), "Management" can complete another entire update, but > the cert that it passes back to the guest will be stale relative to the > key used to sign the attestation report. I was thinking userspace would hold the lock across SEV_CMD_SNP_GUEST_REQUEST. QEMU: a) readlock vlek.cert b) copy cert into guest buffer c) set kvm_run->immediate_exit d) invoke KVM_RUN e) KVM sends SEV_CMD_SNP_GUEST_REQUEST to PSP f) KVM exits to userspace with -EINTR g) unlock vlek.cert h) invoke KVM_RUN (resume the guest) > If we need to take more time to explore other options it's not > absolutely necessary to have the kernel solve this now. But every userspace > will need to solve it in some way so it seemed like it might be nice to > have a simple reference implementation to start with. Shoving something into the kernel is not a "reference implementation", especially not when it impacts the ABI of multiple subsystems.
diff --git a/Documentation/virt/coco/sev-guest.rst b/Documentation/virt/coco/sev-guest.rst index de68d3a4b540..ab192a008ba7 100644 --- a/Documentation/virt/coco/sev-guest.rst +++ b/Documentation/virt/coco/sev-guest.rst @@ -128,8 +128,6 @@ the SEV-SNP specification for further details. The SNP_GET_EXT_REPORT ioctl is similar to the SNP_GET_REPORT. The difference is related to the additional certificate data that is returned with the report. -The certificate data returned is being provided by the hypervisor through the -SNP_SET_EXT_CONFIG. The ioctl uses the SNP_GUEST_REQUEST (MSG_REPORT_REQ) command provided by the SEV-SNP firmware to get the attestation report. @@ -195,6 +193,54 @@ them into the system after obtaining them from the KDS, and corresponds closely to the SNP_VLEK_LOAD firmware command specified in the SEV-SNP spec. +2.8 SNP_PAUSE_ATTESTATION / SNP_RESUME_ATTESTATION +-------------------------------------------------- +:Technology: sev-snp +:Type: hypervisor ioctl cmd +:Parameters (out): struct sev_user_data_snp_pause_transaction +:Returns (out): 0 on success, -negative on error + +When requesting attestation reports, SNP guests have the option of issuing +an extended guest request which allows host userspace to supply additional +certificate data that can be used to validate the signature used to sign +the attestation report. This signature is generated using a key that is +derived from the reported TCB that can be set via the SNP_SET_CONFIG and +SNP_COMMIT ioctls, so the accompanying certificate data needs to be kept in +sync with the changes made to the reported TCB via these ioctls. + +Similarly, interfaces like SNP_LOAD_VLEK can modify the key used to sign +the attestation reports, which may in turn require updating the certificate +data provided to guests via extended guest requests. + +To allow for updating the reported TCB, endorsement key, and any certificate +data in a manner that is atomic to guests, the SNP_PAUSE_ATTESTATION and +SNP_RESUME_ATTESTATION commands are provided. + +After SNP_PAUSE_ATTESTATION is issued, any attestation report requests via +extended guest requests that are in-progress, or received after +SNP_PAUSE_ATTESTATION is issued, will result in the guest receiving a +GHCB-defined error message instructing it to retry the request. Once all +the desired reported TCB, endorsement keys, or certificate data updates +are completed on the host, the SNP_RESUME_ATTESTATION command must be +issued to allow guest attestation requests to proceed. + +In general, hosts should serialize updates of this sort and never have more +than 1 outstanding transaction in flight that could result in the +interleaving of multiple SNP_PAUSE_ATTESTATION/SNP_RESUME_ATTESTATION pairs. +To guard against this, SNP_PAUSE_ATTESTATION will fail if another process +has already paused attestation requests. + +However, there may be occassions where a transaction needs to be aborted due +to unexpected activity in userspace such as timeouts, crashes, etc., so +SNP_RESUME_ATTESTATION will always succeed. Nonetheless, this could +potentially lead to SNP_RESUME_ATTESTATION being called out of sequence, so +to allow for callers of SNP_{PAUSE,RESUME}_ATTESTATION to detect such +occurrences, each ioctl will return a transaction ID in the response so the +caller can monitor whether the start/end ID both match. If they don't, the +caller should assume that attestation has been paused/resumed unexpectedly, +and take whatever measures it deems necessary such as logging, reporting, +auditing the sequence of events. + 3. SEV-SNP CPUID Enforcement ============================ diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h index 3a06f06b847a..ee24ef815e35 100644 --- a/arch/x86/include/asm/sev.h +++ b/arch/x86/include/asm/sev.h @@ -82,6 +82,8 @@ extern void vc_no_ghcb(void); extern void vc_boot_ghcb(void); extern bool handle_vc_boot_ghcb(struct pt_regs *regs); +extern struct mutex snp_pause_attestation_lock; + /* PVALIDATE return codes */ #define PVALIDATE_FAIL_SIZEMISMATCH 6 @@ -272,6 +274,8 @@ int rmp_make_private(u64 pfn, u64 gpa, enum pg_level level, u32 asid, bool immut int rmp_make_shared(u64 pfn, enum pg_level level); void snp_leak_pages(u64 pfn, unsigned int npages); void kdump_sev_callback(void); +int snp_pause_attestation(u64 *transaction_id); +void snp_resume_attestation(u64 *transaction_id); #else static inline bool snp_probe_rmptable_info(void) { return false; } static inline int snp_lookup_rmpentry(u64 pfn, bool *assigned, int *level) { return -ENODEV; } @@ -285,6 +289,8 @@ static inline int rmp_make_private(u64 pfn, u64 gpa, enum pg_level level, u32 as static inline int rmp_make_shared(u64 pfn, enum pg_level level) { return -ENODEV; } static inline void snp_leak_pages(u64 pfn, unsigned int npages) {} static inline void kdump_sev_callback(void) { } +static inline int snp_pause_attestation(u64 *transaction_id) { return 0; } +static inline void snp_resume_attestation(u64 *transaction_id) {} #endif #endif diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c index ab0e8448bb6e..b75f2e7d4012 100644 --- a/arch/x86/virt/svm/sev.c +++ b/arch/x86/virt/svm/sev.c @@ -70,6 +70,11 @@ static DEFINE_SPINLOCK(snp_leaked_pages_list_lock); static unsigned long snp_nr_leaked_pages; +/* For synchronizing TCB/certificate updates with extended guest requests */ +DEFINE_MUTEX(snp_pause_attestation_lock); +static u64 snp_transaction_id; +static bool snp_attestation_paused; + #undef pr_fmt #define pr_fmt(fmt) "SEV-SNP: " fmt @@ -568,3 +573,41 @@ void kdump_sev_callback(void) if (cc_platform_has(CC_ATTR_HOST_SEV_SNP)) wbinvd(); } + +int snp_pause_attestation(u64 *transaction_id) +{ + mutex_lock(&snp_pause_attestation_lock); + + if (snp_attestation_paused) { + mutex_unlock(&snp_pause_attestation_lock); + return -EBUSY; + } + + /* + * The actual transaction ID update will happen when + * snp_resume_attestation() is called, so return + * the *anticipated* transaction ID that will be + * returned by snp_resume_attestation(). This is + * to ensure that unbalanced/aborted transactions will + * be noticeable when the caller that started the + * transaction calls snp_resume_attestation(). + */ + *transaction_id = snp_transaction_id + 1; + snp_attestation_paused = true; + + mutex_unlock(&snp_pause_attestation_lock); + + return 0; +} +EXPORT_SYMBOL_GPL(snp_pause_attestation); + +void snp_resume_attestation(u64 *transaction_id) +{ + mutex_lock(&snp_pause_attestation_lock); + + snp_attestation_paused = false; + *transaction_id = ++snp_transaction_id; + + mutex_unlock(&snp_pause_attestation_lock); +} +EXPORT_SYMBOL_GPL(snp_resume_attestation); diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c index 97a7959406ee..7eb18a273731 100644 --- a/drivers/crypto/ccp/sev-dev.c +++ b/drivers/crypto/ccp/sev-dev.c @@ -2060,6 +2060,47 @@ static int sev_ioctl_do_snp_vlek_load(struct sev_issue_cmd *argp, bool writable) return ret; } +static int sev_ioctl_do_snp_pause_attestation(struct sev_issue_cmd *argp, bool writable) +{ + struct sev_user_data_snp_pause_attestation transaction = {0}; + struct sev_device *sev = psp_master->sev_data; + int ret; + + if (!sev->snp_initialized || !argp->data) + return -EINVAL; + + if (!writable) + return -EPERM; + + ret = snp_pause_attestation(&transaction.id); + if (ret) + return ret; + + if (copy_to_user((void __user *)argp->data, &transaction, sizeof(transaction))) + return -EFAULT; + + return 0; +} + +static int sev_ioctl_do_snp_resume_attestation(struct sev_issue_cmd *argp, bool writable) +{ + struct sev_user_data_snp_pause_attestation transaction = {0}; + struct sev_device *sev = psp_master->sev_data; + + if (!sev->snp_initialized || !argp->data) + return -EINVAL; + + if (!writable) + return -EPERM; + + snp_resume_attestation(&transaction.id); + + if (copy_to_user((void __user *)argp->data, &transaction, sizeof(transaction))) + return -EFAULT; + + return 0; +} + static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg) { void __user *argp = (void __user *)arg; @@ -2123,6 +2164,12 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg) case SNP_VLEK_LOAD: ret = sev_ioctl_do_snp_vlek_load(&input, writable); break; + case SNP_PAUSE_ATTESTATION: + ret = sev_ioctl_do_snp_pause_attestation(&input, writable); + break; + case SNP_RESUME_ATTESTATION: + ret = sev_ioctl_do_snp_resume_attestation(&input, writable); + break; default: ret = -EINVAL; goto out; diff --git a/include/uapi/linux/psp-sev.h b/include/uapi/linux/psp-sev.h index 2289b7c76c59..7b35b2814a99 100644 --- a/include/uapi/linux/psp-sev.h +++ b/include/uapi/linux/psp-sev.h @@ -32,6 +32,8 @@ enum { SNP_COMMIT, SNP_SET_CONFIG, SNP_VLEK_LOAD, + SNP_PAUSE_ATTESTATION, + SNP_RESUME_ATTESTATION, SEV_MAX, }; @@ -241,6 +243,16 @@ struct sev_user_data_snp_wrapped_vlek_hashstick { __u8 data[432]; /* In */ } __packed; +/** + * struct sev_user_data_snp_pause_attestation - metadata for pausing attestation + * + * @id: the ID of the transaction started/ended by a call to SNP_PAUSE_ATTESTATION + * or SNP_RESUME_ATTESTATION, respectively. + */ +struct sev_user_data_snp_pause_attestation { + __u64 id; /* Out */ +} __packed; + /** * struct sev_issue_cmd - SEV ioctl parameters *