sgx_encl_may_map()

sgx_encl_may_map()

[Jarkko Sakkinen]

Hi

Couple of remarks that are not reasoned in the code too well:

1. Why to allow to mmap() to a range where pages have differing
   permissions? I think it would be better just to require all
   pages in a range to have the same permissions.
2. Why not require exact match with the PROT bits?
3. Why don't just store SECINFO flags on EADD? Doing
   calc_vma_prot_bits() on fly is not expensive. Now
   data in SECINFO flags is scattered to two different
   fields (desc and vm_max_prot_bits). I'd just have a field
   called secinfo_flags.

This came up when I noted that SGX_IOC_ENCLAVE_ADD_PAGE documentation
was not updated when this permission handling came up. I started to
do it but stumped into these questions. I also wonder why the API
documentation has not been updated...

/Jarkko

Re: sgx_encl_may_map()

[Jarkko Sakkinen]

On Fri, Aug 23, 2019 at 06:02:48PM +0300, Jarkko Sakkinen wrote:
> 3. Why don't just store SECINFO flags on EADD? Doing
>    calc_vma_prot_bits() on fly is not expensive. Now
>    data in SECINFO flags is scattered to two different
>    fields (desc and vm_max_prot_bits). I'd just have a field
>    called secinfo_flags.

Makes sense to have that field as a cache so that we don't have to do
recalc per page in the sgx_encl_may_map() and thus makes sense to keep
TCS tagging in desc.

/Jarkko

Re: sgx_encl_may_map()

[Jarkko Sakkinen]

On Fri, Aug 23, 2019 at 07:04:04PM +0300, Jarkko Sakkinen wrote:
> On Fri, Aug 23, 2019 at 06:02:48PM +0300, Jarkko Sakkinen wrote:
> > 3. Why don't just store SECINFO flags on EADD? Doing
> >    calc_vma_prot_bits() on fly is not expensive. Now
> >    data in SECINFO flags is scattered to two different
> >    fields (desc and vm_max_prot_bits). I'd just have a field
> >    called secinfo_flags.
> 
> Makes sense to have that field as a cache so that we don't have to do
> recalc per page in the sgx_encl_may_map() and thus makes sense to keep
> TCS tagging in desc.

(1) and (2) I will remark in v22 patch review. It is better to do that
way.

I squashed my remaining fixes that I just posted to the patch set.

The final change log for v22 is:

* Alignment checks have been removed from mmap() because it does not define the
  ELRANGE. VMAs only act as windows to the enclave. The semantics compare
  somewhat how mmap() works with regular files.
* We now require user space addresses given to SGX_IOC_ENCLAVE_ADD_PAGE to be
  page aligned so that we can pass the page directly to EADD and do not have
  to do an extra copy. This was made effectively possible by removing the
  worker thread for adding pages.
* The selftest build files have been refined throughout of various glitches
  and work properly in a cross compilation environment such as BuildRoot.
  In addition, libcalls fail the build with an assertion in the linker
  script, if they end up to the enclave binary.
* CONFIG_INTEL_SGX_DRIVER has been removed because you cannot use SGX core
  for anything without having the driver. This could change when KVM support
  is added.
* We require zero permissions in SECINFO for TCS pages because the CPU
  overwrites SECINFO flags with zero permissions and measures the page
  only after that. Allowing to pass TCS with non-zero permissions would
  cause mismatching measurement between the one provided in SIGSTRUCT and
  the one computed by the CPU.

As I noted I can ATM run only selftest as the stress test that I'm using
is not yet working with the latets API changes.

Can you give it a shot?

/Jarkko

Re: sgx_encl_may_map()

[Sean Christopherson]

On Fri, Aug 23, 2019 at 06:02:48PM +0300, Jarkko Sakkinen wrote:
> Hi
> 
> Couple of remarks that are not reasoned in the code too well:
> 
> 1. Why to allow to mmap() to a range where pages have differing
>    permissions? I think it would be better just to require all
>    pages in a range to have the same permissions.

You mean different vm_max_prot_bits?  I don't think we should deny
mapping a mix of R and RW pages with PROT_READ, e.g. map read-only but
have the option to make select pages writable in the future.

> 2. Why not require exact match with the PROT bits?

Toggling W in particular in the PTEs likely has value, e.g. initialize
data with runtime info and then lock the range in the PTEs.

Re: sgx_encl_may_map()

[Jarkko Sakkinen]

On Fri, Aug 23, 2019 at 01:37:09PM -0700, Sean Christopherson wrote:
> On Fri, Aug 23, 2019 at 06:02:48PM +0300, Jarkko Sakkinen wrote:
> > Hi
> > 
> > Couple of remarks that are not reasoned in the code too well:
> > 
> > 1. Why to allow to mmap() to a range where pages have differing
> >    permissions? I think it would be better just to require all
> >    pages in a range to have the same permissions.
> 
> You mean different vm_max_prot_bits?  I don't think we should deny
> mapping a mix of R and RW pages with PROT_READ, e.g. map read-only but
> have the option to make select pages writable in the future.
> 
> > 2. Why not require exact match with the PROT bits?
> 
> Toggling W in particular in the PTEs likely has value, e.g. initialize
> data with runtime info and then lock the range in the PTEs.

Thanks.

This is really important to document. I'll send a kdoc update for the
ioctl.

/Jarkko