[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5f816a61bb95c5d3ea4c26251bb0a4b044aba0e6.camel@kernel.org>
Date: Mon, 18 Oct 2021 15:51:33 +0300
From: Jarkko Sakkinen <jarkko@...nel.org>
To: Paolo Bonzini <pbonzini@...hat.com>, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org
Cc: dave.hansen@...ux.intel.com, seanjc@...gle.com, x86@...nel.org,
yang.zhong@...el.com, bp@...e.de
Subject: Re: [PATCH v3 0/2] x86: sgx_vepc: implement ioctl to EREMOVE all
pages
On Sat, 2021-10-16 at 03:14 -0400, Paolo Bonzini wrote:
> Add to /dev/sgx_vepc a ioctl that brings vEPC pages back to uninitialized
> state with EREMOVE. This is useful in order to match the expectations
> of guests after reboot, and to match the behavior of real hardware.
>
> The ioctl is a cleaner alternative to closing and reopening the
> /dev/sgx_vepc device; reopening /dev/sgx_vepc could be problematic in
> case userspace has sandboxed itself since the time it first opened the
> device, and has thus lost permissions to do so.
>
> If possible, I would like these patches to be included in 5.15 through
> either the x86 or the KVM tree.
>
> Thanks,
>
> Paolo
>
> Changes from RFC:
> - improved commit messages, added documentation
> - renamed ioctl from SGX_IOC_VEPC_REMOVE to SGX_IOC_VEPC_REMOVE_ALL
>
> Change from v1:
> - fixed documentation and code to cover SGX_ENCLAVE_ACT errors
> - removed Tested-by since the code is quite different now
>
> Changes from v2:
> - return EBUSY also if EREMOVE causes a general protection fault
>
> Paolo Bonzini (2):
> x86: sgx_vepc: extract sgx_vepc_remove_page
> x86: sgx_vepc: implement SGX_IOC_VEPC_REMOVE_ALL ioctl
>
> Documentation/x86/sgx.rst | 35 +++++++++++++++++++++
> arch/x86/include/uapi/asm/sgx.h | 2 ++
> arch/x86/kernel/cpu/sgx/virt.c | 63 ++++++++++++++++++++++++++++++---
> 3 files changed, 95 insertions(+), 5 deletions(-)
>
BTW, do you already have patch for QEMU somewhere, which uses
this new functionality? Would like to peek at it just to see
the usage pattern.
Also, can you provide some way to stress test QEMU so that this
code path gets executed? I'm already using QEMU as my main test
platform for SGX, so it's not a huge stretch for me to test it.
This way I can also provide tested-by for the corresponding QEMU
path.
/Jarkko
Powered by blists - more mailing lists