From: Jarkko Sakkinen <jarkko@kernel.org>
To: Reinette Chatre <reinette.chatre@intel.com>
Cc: dave.hansen@linux.intel.com, tglx@linutronix.de, bp@alien8.de,
luto@kernel.org, mingo@redhat.com, linux-sgx@vger.kernel.org,
x86@kernel.org, seanjc@google.com, kai.huang@intel.com,
cathy.zhang@intel.com, cedric.xing@intel.com,
haitao.huang@intel.com, mark.shanahan@intel.com, hpa@zytor.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2 16/32] x86/sgx: Support restricting of enclave page permissions
Date: Wed, 23 Feb 2022 16:46:04 +0100 [thread overview]
Message-ID: <YhZWvFSuax2GI9cQ@iki.fi> (raw)
In-Reply-To: <d6a5c304-d448-5f0c-6367-26dcba872db3@intel.com>
On Tue, Feb 22, 2022 at 10:35:04AM -0800, Reinette Chatre wrote:
> Hi Jarkko,
>
> On 2/20/2022 4:49 PM, Jarkko Sakkinen wrote:
> > On Mon, Feb 07, 2022 at 04:45:38PM -0800, Reinette Chatre wrote:
>
> ...
>
> >> diff --git a/arch/x86/include/uapi/asm/sgx.h b/arch/x86/include/uapi/asm/sgx.h
> >> index 5c678b27bb72..b0ffb80bc67f 100644
> >> --- a/arch/x86/include/uapi/asm/sgx.h
> >> +++ b/arch/x86/include/uapi/asm/sgx.h
> >> @@ -31,6 +31,8 @@ enum sgx_page_flags {
> >> _IO(SGX_MAGIC, 0x04)
> >> #define SGX_IOC_ENCLAVE_RELAX_PERMISSIONS \
> >> _IOWR(SGX_MAGIC, 0x05, struct sgx_enclave_relax_perm)
> >> +#define SGX_IOC_ENCLAVE_RESTRICT_PERMISSIONS \
> >> + _IOWR(SGX_MAGIC, 0x06, struct sgx_enclave_restrict_perm)
> >>
> >> /**
> >> * struct sgx_enclave_create - parameter structure for the
> >> @@ -95,6 +97,25 @@ struct sgx_enclave_relax_perm {
> >> __u64 count;
> >> };
> >>
> >> +/**
> >> + * struct sgx_enclave_restrict_perm - parameters for ioctl
> >> + * %SGX_IOC_ENCLAVE_RESTRICT_PERMISSIONS
> >> + * @offset: starting page offset (page aligned relative to enclave base
> >> + * address defined in SECS)
> >> + * @length: length of memory (multiple of the page size)
> >> + * @secinfo: address for the SECINFO data containing the new permission bits
> >> + * for pages in range described by @offset and @length
> >> + * @result: (output) SGX result code of ENCLS[EMODPR] function
> >> + * @count: (output) bytes successfully changed (multiple of page size)
> >> + */
> >> +struct sgx_enclave_restrict_perm {
> >> + __u64 offset;
> >> + __u64 length;
> >> + __u64 secinfo;
> >> + __u64 result;
> >> + __u64 count;
> >> +};
> >> +
> >> struct sgx_enclave_run;
> >>
> >> /**
>
> ...
>
> >
> > Just a suggestion but these might be a bit less cluttered explanations of
> > the fields:
> >
> > /// SGX_IOC_ENCLAVE_RELAX_PERMISSIONS parameter structure
> > #[repr(C)]
> > pub struct RelaxPermissions {
> > /// In: starting page offset
> > offset: u64,
> > /// In: length of the address range (multiple of the page size)
> > length: u64,
> > /// In: SECINFO containing the relaxed permissions
> > secinfo: u64,
> > /// Out: length of the address range successfully changed
> > count: u64,
> > };
> >
> > /// SGX_IOC_ENCLAVE_RESTRICT_PERMISSIONS parameter structure
> > #[repr(C)]
> > pub struct RestrictPermissions {
> > /// In: starting page offset
> > offset: u64,
> > /// In: length of the address range (multiple of the page size)
> > length: u64,
> > /// In: SECINFO containing the restricted permissions
> > secinfo: u64,
> > /// In: ENCLU[EMODPR] return value
> > result: u64,
> > /// Out: length of the address range successfully changed
> > count: u64,
> > };
>
> In your proposal you shorten the descriptions from the current implementation.
> I do consider the removed information valuable since I believe that it helps
> users understand the kernel interface requirements without needing to be
> familiar with or dig into the kernel code to understand how the provided data
> is used.
>
> For example, you shorten offset to "starting page offset", but what was removed
> was the requirement that this offset has to be page aligned and what the offset
> is relative to. I do believe summarizing these requirements upfront helps
> a user space developer by not needing to dig through kernel code later
> in order to understand why an -EINVAL was received.
>
>
> > I can live with the current ones too but I rewrote them so that I can
> > quickly make sense of the fields later. It's Rust code but the point is
> > the documentation...
>
> Since you do seem to be ok with the current descriptions I would prefer
> to keep them.
Yeah, they are fine to me.
> > Also, it should not be too much trouble to use the struct in user space
> > code even if the struct names are struct sgx_enclave_relax_permissions and
> > struct sgx_enclave_restrict_permissions, given that you most likely have
> > exactly single call-site in the run-time.
>
> Are you requesting that I make the following name changes?
> struct sgx_enclave_relax_perm -> struct sgx_enclave_relax_permissions
> struct sgx_enclave_restrict_perm -> struct sgx_enclave_restrict_permissions
>
> If so, do you want the function names also written out in this way?
> sgx_enclave_relax_perm() -> sgx_enclave_relax_permissions()
> sgx_ioc_enclave_relax_perm() -> sgx_ioc_enclave_relax_permissions()
> sgx_enclave_restrict_perm() -> sgx_enclave_restrict_permissions()
> sgx_ioc_enclave_restrict_perm() -> sgx_ioc_enclave_restrict_permissions()
Yes, unless you have a specific reason to shorten them :-)
> > Other than that, looks quite good.
>
> Thank you very much for reviewing and testing this work.
NP
> Reinette
BR, Jarkko
next prev parent reply other threads:[~2022-02-23 15:45 UTC|newest]
Thread overview: 130+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-08 0:45 [PATCH V2 00/32] x86/sgx and selftests/sgx: Support SGX2 Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 01/32] x86/sgx: Add short descriptions to ENCLS wrappers Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 02/32] x86/sgx: Add wrapper for SGX2 EMODPR function Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 03/32] x86/sgx: Add wrapper for SGX2 EMODT function Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 04/32] x86/sgx: Add wrapper for SGX2 EAUG function Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 05/32] Documentation/x86: Document SGX permission details Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 06/32] x86/sgx: Support VMA permissions more relaxed than enclave permissions Reinette Chatre
2022-03-07 17:10 ` Jarkko Sakkinen
2022-03-07 17:36 ` Reinette Chatre
2022-03-08 8:14 ` Jarkko Sakkinen
2022-03-08 9:06 ` Jarkko Sakkinen
2022-03-08 9:12 ` Jarkko Sakkinen
2022-03-08 16:04 ` Reinette Chatre
2022-03-08 17:00 ` Jarkko Sakkinen
2022-03-08 17:49 ` Reinette Chatre
2022-03-08 18:46 ` Jarkko Sakkinen
2022-03-11 11:06 ` Dr. Greg
2022-02-08 0:45 ` [PATCH V2 07/32] x86/sgx: Add pfn_mkwrite() handler for present PTEs Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 08/32] x86/sgx: x86/sgx: Add sgx_encl_page->vm_run_prot_bits for dynamic permission changes Reinette Chatre
2022-03-04 8:55 ` Jarkko Sakkinen
2022-03-04 19:19 ` Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 09/32] x86/sgx: Export sgx_encl_ewb_cpumask() Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 10/32] x86/sgx: Rename sgx_encl_ewb_cpumask() as sgx_encl_cpumask() Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 11/32] x86/sgx: Move PTE zap code to new sgx_zap_enclave_ptes() Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 12/32] x86/sgx: Make sgx_ipi_cb() available internally Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 13/32] x86/sgx: Create utility to validate user provided offset and length Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 14/32] x86/sgx: Keep record of SGX page type Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 15/32] x86/sgx: Support relaxing of enclave page permissions Reinette Chatre
2022-03-04 8:59 ` Jarkko Sakkinen
2022-02-08 0:45 ` [PATCH V2 16/32] x86/sgx: Support restricting " Reinette Chatre
2022-02-21 0:49 ` Jarkko Sakkinen
2022-02-22 18:35 ` Reinette Chatre
2022-02-23 15:46 ` Jarkko Sakkinen [this message]
2022-02-23 19:55 ` Reinette Chatre
2022-02-28 12:27 ` Jarkko Sakkinen
2022-02-23 19:21 ` Dhanraj, Vijay
2022-02-23 22:42 ` Reinette Chatre
2022-02-28 12:24 ` Jarkko Sakkinen
2022-02-28 13:19 ` Jarkko Sakkinen
2022-02-28 15:16 ` Dave Hansen
2022-02-28 17:44 ` Dhanraj, Vijay
2022-03-01 13:26 ` Jarkko Sakkinen
2022-03-01 13:42 ` Jarkko Sakkinen
2022-03-01 17:48 ` Reinette Chatre
2022-03-02 2:05 ` Jarkko Sakkinen
2022-03-02 2:11 ` Jarkko Sakkinen
2022-03-02 4:03 ` Jarkko Sakkinen
2022-03-02 22:57 ` Reinette Chatre
2022-03-03 16:08 ` Haitao Huang
2022-03-03 21:23 ` Reinette Chatre
2022-03-03 21:44 ` Dave Hansen
2022-03-05 3:19 ` Jarkko Sakkinen
2022-03-06 0:15 ` Jarkko Sakkinen
2022-03-06 0:25 ` Jarkko Sakkinen
2022-03-10 5:43 ` Jarkko Sakkinen
2022-03-10 5:59 ` Jarkko Sakkinen
2022-03-03 23:18 ` Jarkko Sakkinen
2022-03-04 4:03 ` Haitao Huang
2022-03-04 8:30 ` Jarkko Sakkinen
2022-03-04 15:51 ` Haitao Huang
2022-03-05 1:02 ` Jarkko Sakkinen
2022-03-06 14:24 ` Haitao Huang
2022-03-03 23:12 ` Jarkko Sakkinen
2022-03-04 0:48 ` Reinette Chatre
2022-03-10 6:10 ` Jarkko Sakkinen
2022-03-10 18:33 ` Haitao Huang
2022-03-11 12:10 ` Jarkko Sakkinen
2022-03-11 12:16 ` Jarkko Sakkinen
2022-03-11 12:33 ` Jarkko Sakkinen
2022-03-11 17:53 ` Reinette Chatre
2022-03-11 18:11 ` Jarkko Sakkinen
2022-03-11 19:28 ` Reinette Chatre
2022-03-14 3:42 ` Jarkko Sakkinen
2022-03-14 3:45 ` Jarkko Sakkinen
2022-03-14 3:54 ` Jarkko Sakkinen
2022-03-14 15:32 ` Reinette Chatre
2022-03-17 4:30 ` Jarkko Sakkinen
2022-03-17 22:08 ` Reinette Chatre
2022-03-17 22:51 ` Jarkko Sakkinen
2022-03-18 0:11 ` Reinette Chatre
2022-03-20 0:24 ` Jarkko Sakkinen
2022-03-28 23:22 ` Reinette Chatre
2022-03-30 15:00 ` Jarkko Sakkinen
2022-03-30 15:02 ` Jarkko Sakkinen
2022-03-14 2:49 ` Jarkko Sakkinen
2022-03-14 2:50 ` Jarkko Sakkinen
2022-03-14 2:58 ` Jarkko Sakkinen
2022-03-14 15:39 ` Haitao Huang
2022-03-17 4:34 ` Jarkko Sakkinen
2022-03-17 14:42 ` Haitao Huang
2022-03-17 4:37 ` Jarkko Sakkinen
2022-03-17 14:47 ` Haitao Huang
2022-03-17 7:01 ` Jarkko Sakkinen
2022-03-17 7:11 ` Jarkko Sakkinen
2022-03-17 14:28 ` Haitao Huang
2022-03-17 21:50 ` Jarkko Sakkinen
2022-03-17 22:00 ` Jarkko Sakkinen
2022-03-17 22:23 ` Jarkko Sakkinen
2022-02-08 0:45 ` [PATCH V2 17/32] selftests/sgx: Add test for EPCM permission changes Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 18/32] selftests/sgx: Add test for TCS page " Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 19/32] x86/sgx: Support adding of pages to an initialized enclave Reinette Chatre
2022-02-19 11:57 ` Jarkko Sakkinen
2022-02-19 12:01 ` Jarkko Sakkinen
2022-02-20 18:40 ` Jarkko Sakkinen
2022-02-22 19:19 ` Reinette Chatre
2022-02-23 15:46 ` Jarkko Sakkinen
2022-03-07 16:16 ` Jarkko Sakkinen
2022-02-08 0:45 ` [PATCH V2 20/32] x86/sgx: Tighten accessible memory range after enclave initialization Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 21/32] selftests/sgx: Test two different SGX2 EAUG flows Reinette Chatre
2022-03-07 16:39 ` Jarkko Sakkinen
2022-02-08 0:45 ` [PATCH V2 22/32] x86/sgx: Support modifying SGX page type Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 23/32] x86/sgx: Support complete page removal Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 24/32] Documentation/x86: Introduce enclave runtime management section Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 25/32] selftests/sgx: Introduce dynamic entry point Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 26/32] selftests/sgx: Introduce TCS initialization enclave operation Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 27/32] selftests/sgx: Test complete changing of page type flow Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 28/32] selftests/sgx: Test faulty enclave behavior Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 29/32] selftests/sgx: Test invalid access to removed enclave page Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 30/32] selftests/sgx: Test reclaiming of untouched page Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 31/32] x86/sgx: Free up EPC pages directly to support large page ranges Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 32/32] selftests/sgx: Page removal stress test Reinette Chatre
2022-02-22 20:27 ` [PATCH V2 00/32] x86/sgx and selftests/sgx: Support SGX2 Nathaniel McCallum
2022-02-22 22:39 ` Reinette Chatre
2022-02-23 13:24 ` Nathaniel McCallum
2022-02-23 18:25 ` Reinette Chatre
2022-03-02 16:57 ` Nathaniel McCallum
2022-03-02 21:20 ` Reinette Chatre
2022-03-03 1:13 ` Nathaniel McCallum
2022-03-03 17:49 ` Reinette Chatre
2022-03-04 0:57 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YhZWvFSuax2GI9cQ@iki.fi \
--to=jarkko@kernel.org \
--cc=bp@alien8.de \
--cc=cathy.zhang@intel.com \
--cc=cedric.xing@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=haitao.huang@intel.com \
--cc=hpa@zytor.com \
--cc=kai.huang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sgx@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mark.shanahan@intel.com \
--cc=mingo@redhat.com \
--cc=reinette.chatre@intel.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).