Re: [PATCH 05/25] x86/sgx: Introduce runtime protection bits

[Reinette Chatre]

Hi Jarkko,

On 12/4/2021 3:57 PM, Jarkko Sakkinen wrote:
> On Fri, Dec 03, 2021 at 11:28:04AM -0800, Andy Lutomirski wrote:
> > On 12/1/21 11:23, Reinette Chatre wrote:
> > > Enclave creators declare their paging permission intent at the time
> > > the pages are added to the enclave. These paging permissions are
> > > vetted when pages are added to the enclave and stashed off
> > > (in sgx_encl_page->vm_max_prot_bits) for later comparison with
> > > enclave PTEs.
> >
> > I'm a bit confused here. ENCLU[EMODPE] allows the enclave to change the EPCM
> > permission bits however it likes with no oversight from the kernel.  So we
> > end up with a whole bunch of permission masks:
> >
> > The PTE: controlled by complex kernel policy
> >
> > The VMA: with your series, this is entirely controlled by userspace.  I
> > think I'm fine with that.
> >
> > vm_max_prot_bits: populated from secinfo at setup time, unless I missed
> > something that changes it later.  Maybe I'm confused or missed something in
> > one of the patches,
> >
> > vm_run_prot_bits: populated from some combination of ioctls.  I'm entirely
> > lost as to what this is for.
> >
> > EPCM bits: controlled by the guest.  basically useless for any host purpose
> > on SGX2 hardware (with or without kernel support -- the enclave can do
> > ENCLU[EMODPE] whether we like it or not, even on old kernels)
> >
> > So I guess I don't understand the purpose of this patch	or of the rules in
> > the later patches, and I feel like this is getting more complicated than
> > makes sense.
> >
> >
> > Could we perhaps make vm_max_prot_bits dynamic or at least controllable in
> > some useful way?  My initial proposal (years ago) was for vm_max_prot_bits
> > to be *separately* configured at initial load time instead of being inferred
> > from secinfo with the intent being that the user untrusted runtime would set
> > it appropriately.  I have no problem with allowing runtime changes as long
> > as the security policy makes sense and it's kept consistent with PTEs.
>
> This is a valid question. Since EMODPE exists why not just make things for
> EMODPE, and ignore EMODPR altogether?

I believe that we should support the best practice of principle of least 
privilege - once a page no longer needs a particular permission there 
should be a way to remove it (the unneeded permission).

Reinette