ptp: kvm: Use decrypted memory in confidential guest on x86
Subsystems (3)
PATCH RESEND v2 1/1 ptp: kvm: Use decrypted memory in confidential guest on x86
KVM_HC_CLOCK_PAIRING currently fails inside SEV-SNP guests because the guest passes an address to static data to the host. In confidential computing the host can't access arbitrary guest memory so handling the hypercall runs into an "rmpfault". To make the hypercall work, the guest needs to explicitly mark the memory as decrypted. Do that in kvm_arch_ptp_init(), but retain the previous behavior for non-confidential guests to save us from having to allocate memory.
Add a new arch-specific function (kvm_arch_ptp_exit()) to free the allocation and mark the memory as encrypted again.
---
Hi,
I would love to not allocate a whole page just for this driver, swiotlb is decrypted but I don't have access to a 'struct device' here. Does anyone have any suggestion?
Jeremi
Changes since v1:
- forgot to commit include/linux/ptp_kvm.h
drivers/ptp/ptp_kvm_arm.c | 4 +++ drivers/ptp/ptp_kvm_common.c | 1 + drivers/ptp/ptp_kvm_x86.c | 59 +++++++++++++++++++++++++++++------- include/linux/ptp_kvm.h | 1 + 4 files changed, 54 insertions(+), 11 deletions(-)
drivers/ptp/ptp_kvm_arm.c +4 -0
@@ -22,6 +22,10 @@ int kvm_arch_ptp_init(void)return 0 ; } +void kvm_arch_ptp_exit (void ) +{ +} +int kvm_arch_ptp_get_clock (struct timespec64 *ts) {return kvm_arch_ptp_get_crosststamp (NULL , ts,NULL );
drivers/ptp/ptp_kvm_common.c +1 -0
@@ -130,6 +130,7 @@ static struct kvm_ptp_clock kvm_ptp_clock; static void __exit ptp_kvm_exit(void) {ptp_clock_unregister (kvm_ptp_clock.ptp_clock); +kvm_arch_ptp_exit (); }static int __init ptp_kvm_init (void )
drivers/ptp/ptp_kvm_x86.c +48 -11
92 lines not on this page · raw message
include/linux/ptp_kvm.h +1 -0
@@ -14,6 +14,7 @@ struct timespec64;struct clocksource ;int kvm_arch_ptp_init (void ); +void kvm_arch_ptp_exit (void );int kvm_arch_ptp_get_clock (struct timespec64 *ts);int kvm_arch_ptp_get_crosststamp (u64 *cycle,struct timespec64 *tspec,struct clocksource **cs);
Signature · 1 line
2.25.1
Quoted 12 lines · Jeremi Piotrowski
KVM_HC_CLOCK_PAIRINGcurrently fails inside SEV-SNP guests because the guest passes an address to static data to the host. In confidential computing the host can't access arbitrary guest memory so handling the hypercall runs into an "rmpfault". To make the hypercall work, the guest needs to explicitly mark the memory as decrypted. Do that inkvm_arch_ptp_init(), but retain the previous behavior for non-confidential guests to save us from having to allocate memory.Add a new arch-specific function (
kvm_arch_ptp_exit()) to free the allocation and mark the memory as encrypted again.Signed-off-by Jeremi Piotrowski <[email protected]>
Quoted 9 lines
---
Hi,I would love to not allocate a whole page just for this driver, swiotlb is decrypted but I don't have access to a 'struct device' here. Does anyone have any suggestion?
Jeremi
Hi,
Does anyone have any comments or suggestions? Or can this be merged.
Jeremi
Quoted 147 lines
Changes since v1:
- forgot to commitinclude/linux/ptp_kvm.hdrivers/ptp/ptp_kvm_arm.c | 4 +++ drivers/ptp/ptp_kvm_common.c | 1 + drivers/ptp/ptp_kvm_x86.c | 59 +++++++++++++++++++++++++++++------- include/linux/ptp_kvm.h | 1 + 4 files changed, 54 insertions(+), 11 deletions(-)drivers/ptp/ptp_kvm_arm.c +4
-0@@ -22,6 +22,10 @@ int kvm_arch_ptp_init(void)return 0 ; } +void kvm_arch_ptp_exit (void ) +{ +} +int kvm_arch_ptp_get_clock (struct timespec64 *ts) {return kvm_arch_ptp_get_crosststamp (NULL , ts,NULL );drivers/ptp/ptp_kvm_common.c +1
-0@@ -130,6 +130,7 @@ static struct kvm_ptp_clock kvm_ptp_clock; static void __exit ptp_kvm_exit(void) {ptp_clock_unregister (kvm_ptp_clock.ptp_clock); +kvm_arch_ptp_exit (); }static int __init ptp_kvm_init (void )drivers/ptp/ptp_kvm_x86.c +48
-11@@ -14,27 +14,64 @@#include <uapi/linux/kvm_para.h> #include <linux/ptp_clock_kernel.h> #include <linux/ptp_kvm.h> +#include <linux/set_memory.h> static phys_addr_t clock_pair_gpa; -static struct kvm_clock_pairing clock_pair; +static struct kvm_clock_pairing clock_pair_glbl; +static struct kvm_clock_pairing *clock_pair;int kvm_arch_ptp_init (void ) { +struct page *p;long ret;if (!kvm_para_available ())return -ENODEV ; - clock_pair_gpa =slow_virt_to_phys (&clock_pair); -if (!pvclock_get_pvti_cpu0_va ()) -return -ENODEV ; +if (cc_platform_has (CC_ATTR_GUEST_MEM_ENCRYPT )) { + p =alloc_page (GFP_KERNEL | __GFP_ZERO); +if (!p) +return -ENOMEM ; + + clock_pair =page_address (p); + ret =set_memory_decrypted ((unsigned long )clock_pair,1 ); +if (ret) { +__free_page (p); + clock_pair =NULL ; + goto nofree; + } + }else { + clock_pair = &clock_pair_glbl; + } + + clock_pair_gpa =slow_virt_to_phys (clock_pair); +if (!pvclock_get_pvti_cpu0_va ()) { + ret = -ENODEV ; + goto err; + } ret =kvm_hypercall2 (KVM_HC_CLOCK_PAIRING , clock_pair_gpa,KVM_CLOCK_PAIRING_WALLCLOCK ); -if (ret == -KVM_ENOSYS ) -return -ENODEV ; +if (ret == -KVM_ENOSYS ) { + ret = -ENODEV ; + goto err; + }return ret; + +err: +kvm_arch_ptp_exit (); +nofree: +return ret; +} + +void kvm_arch_ptp_exit (void ) +{ +if (cc_platform_has (CC_ATTR_GUEST_MEM_ENCRYPT )) { +WARN_ON (set_memory_encrypted ((unsigned long )clock_pair,1 )); +free_page ((unsigned long )clock_pair); + clock_pair =NULL ; + } }int kvm_arch_ptp_get_clock (struct timespec64 *ts)@@ -49,8 +86,8 @@ int kvm_arch_ptp_get_clock(struct timespec64 *ts)return -EOPNOTSUPP ; } - ts->tv_sec = clock_pair.sec; - ts->tv_nsec = clock_pair.nsec; + ts->tv_sec = clock_pair->sec; + ts->tv_nsec = clock_pair->nsec;return 0 ; }@@ -81,9 +118,9 @@ int kvm_arch_ptp_get_crosststamp(u64 *cycle, struct timespec64 *tspec,pr_err_ratelimited ("clock pairing hypercall ret %lu\n" , ret);return -EOPNOTSUPP ; } - tspec->tv_sec = clock_pair.sec; - tspec->tv_nsec = clock_pair.nsec; - *cycle =__pvclock_read_cycles (src, clock_pair.tsc); + tspec->tv_sec = clock_pair->sec; + tspec->tv_nsec = clock_pair->nsec; + *cycle =__pvclock_read_cycles (src, clock_pair->tsc); }while (pvclock_read_retry (src, version)); *cs = &kvm_clock;include/linux/ptp_kvm.h +1
-0@@ -14,6 +14,7 @@ struct timespec64;struct clocksource ;int kvm_arch_ptp_init (void ); +void kvm_arch_ptp_exit (void );int kvm_arch_ptp_get_clock (struct timespec64 *ts);int kvm_arch_ptp_get_crosststamp (u64 *cycle,struct timespec64 *tspec,struct clocksource **cs);
Jakub Kicinski
maintainerQuoted 7 lines · On Fri, 17 Mar 2023 16:59:37 +0100 Jeremi Piotrowski wrote:
Quoted 5 lines
Hi,
I would love to not allocate a whole page just for this driver, swiotlb is decrypted but I don't have access to a 'struct device' here. Does anyone have any suggestion?
Does anyone have any comments or suggestions? Or can this be merged.
Looks like the patch got miscategorized in patchwork. It LGTM, I'll apply it to netdev if nobody speaks up before the end of the day..
This patch was applied to netdev/net-next.git (main) by Jakub Kicinski <[email protected]>:
Hello:
This patch was applied to netdev/net-next.git (main) by Jakub Kicinski <[email protected]>:
Quoted 9 lines · On Wed, 8 Mar 2023 15:05:31 +0000 you wrote:
KVM_HC_CLOCK_PAIRINGcurrently fails inside SEV-SNP guests because the guest passes an address to static data to the host. In confidential computing the host can't access arbitrary guest memory so handling the hypercall runs into an "rmpfault". To make the hypercall work, the guest needs to explicitly mark the memory as decrypted. Do that inkvm_arch_ptp_init(), but retain the previous behavior for non-confidential guests to save us from having to allocate memory.[...]
Here is the summary with links:
- [v2,RESEND] ptp: kvm: Use decrypted memory in confidential guest on x86
https://git.kernel.org/netdev/net-next/c/6365ba64b4db
You are awesome, thank you!
Signature · 2 lines
Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html