From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: linux-sgx@vger.kernel.org,
Sean Christopherson <sean.j.christpherson@intel.com>,
Shay Katz-zamir <shay.katz-zamir@intel.com>,
Serge Ayoun <serge.ayoun@intel.com>
Subject: Re: [PATCH 5/5] x86/sgx: Rename vm_prot_bits as max_vm_flags
Date: Wed, 21 Aug 2019 21:00:46 -0700 [thread overview]
Message-ID: <20190822040046.GW29345@linux.intel.com> (raw)
In-Reply-To: <20190819152544.7296-6-jarkko.sakkinen@linux.intel.com>
On Mon, Aug 19, 2019 at 06:25:44PM +0300, Jarkko Sakkinen wrote:
> vm_prot_bits is very bad and misleading name for the field in struct
> sgx_encl_page. What the field contains exactly is not @prot of
> mprotect() but the *maximum* VM flags for the VMA that contains the
> given enclave page.
>
> Thus, the only viable name for the field is max_vm_flags. In functions
> that also pass VM flags the parameter name is renamed from vm_prot_bits
> to vm_flags.
Why not max_vm_prot_bits? 'vm_flags' implies the field contains all
manner of VM_FLAGS. The 'vm_prot_bits' name was derived from
calc_vm_prot_bits() to provide this differentiation, especially since
there's also a calc_vm_flag_bits(),
> To summarize, this commit makes two improvements to clarify the
> permission handling:
>
> 1. Changes the name to match better the contents.
> 2. Uses naming to differentiate the field inside the struct and
> the parameter passed to functions.
>
> Cc: Sean Christopherson <sean.j.christpherson@intel.com>
> Cc: Shay Katz-zamir <shay.katz-zamir@intel.com>
> Cc: Serge Ayoun <serge.ayoun@intel.com>
> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> ---
> arch/x86/kernel/cpu/sgx/driver/ioctl.c | 2 +-
> arch/x86/kernel/cpu/sgx/encl.c | 14 +++++++-------
> arch/x86/kernel/cpu/sgx/encl.h | 4 ++--
> 3 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/sgx/driver/ioctl.c b/arch/x86/kernel/cpu/sgx/driver/ioctl.c
> index 2415dcb20a6e..b61e06daad6e 100644
> --- a/arch/x86/kernel/cpu/sgx/driver/ioctl.c
> +++ b/arch/x86/kernel/cpu/sgx/driver/ioctl.c
> @@ -261,7 +261,7 @@ static struct sgx_encl_page *sgx_encl_page_alloc(struct sgx_encl *encl,
> encl_page->encl = encl;
>
> /* Calculate maximum of the VM flags for the page. */
> - encl_page->vm_prot_bits = calc_vm_prot_bits(prot, 0);
> + encl_page->max_vm_flags = calc_vm_prot_bits(prot, 0);
>
> ret = radix_tree_insert(&encl->page_tree, PFN_DOWN(encl_page->desc),
> encl_page);
> diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
> index a20d498e9dcd..890eacb45a80 100644
> --- a/arch/x86/kernel/cpu/sgx/encl.c
> +++ b/arch/x86/kernel/cpu/sgx/encl.c
> @@ -292,25 +292,25 @@ static unsigned int sgx_vma_fault(struct vm_fault *vmf)
> * @encl: an enclave
> * @start: lower bound of the address range, inclusive
> * @end: upper bound of the address range, exclusive
> - * @vm_prot_bits: requested protections of the address range
> + * @vm_flags: requested VM flags for the address range
> *
> * Iterate through the enclave pages contained within [@start, @end) to verify
> - * the permissions requested by @vm_prot_bits do not exceed that of any enclave
> - * page to be mapped. Page addresses that do not have an associated enclave
> - * page are interpreted to zero permissions.
> + * the the VM flags do not exceed that of any enclave page to be mapped. Page
> + * addresses that do not have an associated enclave page are interpreted to zero
> + * permissions.
> *
> * Return:
> * 0 on success,
> * -EACCES if VMA permissions exceed enclave page permissions
> */
> int sgx_encl_may_map(struct sgx_encl *encl, unsigned long start,
> - unsigned long end, unsigned long vm_prot_bits)
> + unsigned long end, unsigned long vm_flags)
If 'vm_prot_bits' is distasteful, 'prot' would be preferrable as its used
throughout the kernel for variable that hold only the prot bits.
> {
> unsigned long idx, idx_start, idx_end;
> struct sgx_encl_page *page;
>
> /* PROT_NONE always succeeds. */
> - if (!vm_prot_bits)
> + if (!vm_flags)
> return 0;
>
> idx_start = PFN_DOWN(start);
> @@ -321,7 +321,7 @@ int sgx_encl_may_map(struct sgx_encl *encl, unsigned long start,
> page = radix_tree_lookup(&encl->page_tree, idx);
> mutex_unlock(&encl->lock);
>
> - if (!page || (~page->vm_prot_bits & vm_prot_bits))
> + if (!page || (~page->max_vm_flags & vm_flags))
> return -EACCES;
> }
>
> diff --git a/arch/x86/kernel/cpu/sgx/encl.h b/arch/x86/kernel/cpu/sgx/encl.h
> index d3a1687ed84c..0e28b784a8c5 100644
> --- a/arch/x86/kernel/cpu/sgx/encl.h
> +++ b/arch/x86/kernel/cpu/sgx/encl.h
> @@ -44,7 +44,7 @@ enum sgx_encl_page_desc {
>
> struct sgx_encl_page {
> unsigned long desc;
> - unsigned long vm_prot_bits;
> + unsigned long max_vm_flags;
> struct sgx_epc_page *epc_page;
> struct sgx_va_page *va_page;
> struct sgx_encl *encl;
> @@ -134,6 +134,6 @@ void sgx_free_va_slot(struct sgx_va_page *va_page, unsigned int offset);
> bool sgx_va_page_full(struct sgx_va_page *va_page);
>
> int sgx_encl_may_map(struct sgx_encl *encl, unsigned long start,
> - unsigned long end, unsigned long vm_prot_bits);
> + unsigned long end, unsigned long vm_flags);
>
> #endif /* _X86_ENCL_H */
> --
> 2.20.1
>
next prev parent reply other threads:[~2019-08-22 4:00 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-19 15:25 [PATCH 0/5] x86/sgx: Improve permission handing Jarkko Sakkinen
2019-08-19 15:25 ` [PATCH 1/5] x86/sgx: Document permission handling better Jarkko Sakkinen
2019-08-22 3:43 ` Sean Christopherson
2019-08-22 16:04 ` Jarkko Sakkinen
2019-08-19 15:25 ` [PATCH 2/5] x86/sgx: Use memchr_inv() in sgx_validate_secinfo() Jarkko Sakkinen
2019-08-22 3:47 ` Sean Christopherson
2019-08-22 16:20 ` Jarkko Sakkinen
2019-08-19 15:25 ` [PATCH 3/5] x86/sgx: Make sgx_validate_secinfo() more readable Jarkko Sakkinen
2019-08-22 3:48 ` Sean Christopherson
2019-08-22 16:26 ` Jarkko Sakkinen
2019-08-22 10:39 ` Ayoun, Serge
2019-08-22 16:45 ` Jarkko Sakkinen
2019-08-19 15:25 ` [PATCH 4/5] x86/sgx: Validate TCS permssions in sgx_validate_secinfo() Jarkko Sakkinen
2019-08-21 18:45 ` Jarkko Sakkinen
2019-08-22 11:33 ` Ayoun, Serge
2019-08-22 14:27 ` Sean Christopherson
2019-08-22 16:46 ` Jarkko Sakkinen
2019-08-22 16:59 ` Jarkko Sakkinen
2019-08-22 3:55 ` Sean Christopherson
2019-08-22 16:31 ` Jarkko Sakkinen
2019-08-22 16:34 ` Sean Christopherson
2019-08-23 0:39 ` Jarkko Sakkinen
2019-08-23 0:57 ` Jarkko Sakkinen
2019-08-23 2:05 ` Sean Christopherson
2019-08-23 13:41 ` Jarkko Sakkinen
2019-08-22 16:38 ` Jarkko Sakkinen
2019-08-19 15:25 ` [PATCH 5/5] x86/sgx: Rename vm_prot_bits as max_vm_flags Jarkko Sakkinen
2019-08-22 4:00 ` Sean Christopherson [this message]
2019-08-22 16:43 ` 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=20190822040046.GW29345@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=linux-sgx@vger.kernel.org \
--cc=sean.j.christpherson@intel.com \
--cc=serge.ayoun@intel.com \
--cc=shay.katz-zamir@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.