On Sat, Jan 15, 2022 at 01:56:55PM +0200, Jarkko Sakkinen wrote: > On Sat, Jan 15, 2022 at 03:18:04AM +0200, Jarkko Sakkinen wrote: > > On Fri, Jan 14, 2022 at 04:41:59PM -0800, Reinette Chatre wrote: > > > Hi Jarkko, > > > > > > On 1/14/2022 4:27 PM, Jarkko Sakkinen wrote: > > > > On Fri, Jan 14, 2022 at 04:01:33PM -0800, Reinette Chatre wrote: > > > >> Hi Jarkko, > > > >> > > > >> On 1/14/2022 3:15 PM, Jarkko Sakkinen wrote: > > > >>> On Fri, Jan 14, 2022 at 03:05:21PM -0800, Reinette Chatre wrote: > > > >>>> Hi Jarkko, > > > >>> > > > >>> How enclave can check a page range that EPCM has the expected permissions? > > > >> > > > >> Only way to change EPCM permissions from outside enclave is to run ENCLS[EMODPR] > > > >> that needs to be accepted from within the enclave via ENCLU[EACCEPT]. At that > > > >> time the enclave provides the expected permissions and that will fail > > > >> if there is a mismatch with the EPCM permissions (SGX_PAGE_ATTRIBUTES_MISMATCH). > > > > > > > > This is a very valid point but that does make the introspection possible > > > > only at the time of EACCEPT. > > > > > > > > It does not give tools for enclave to make sure that EMODPR-ETRACK dance > > > > was ever exercised. > > > > > > Could you please elaborate? EACCEPT is available to the enclave as a tool > > > and it would fail if ETRACK was not completed (error SGX_NOT_TRACKED). > > > > > > Here is the relevant snippet from the SDM from the section where it > > > describes EACCEPT: > > > > > > IF (Tracking not correct) > > > THEN > > > RFLAGS.ZF := 1; > > > RAX := SGX_NOT_TRACKED; > > > GOTO DONE; > > > FI; > > > > > > Reinette > > > > Yes, if enclave calls EACCEPT it does the necessary introspection and makes > > sure that ETRACK is completed. I have trouble understanding how enclave > > makes sure that EACCEPT was called. > > I'm not concerned of anything going wrong once EMODPR has been started. > > The problem nails down to that the whole EMODPR process is spawned by > the entity that is not trusted so maybe that should further broke down > to three roles: > > 1. Build process B > 2. Runner process R. > 3. Enclave E. > > And to the costraint that we trust B *more* than R. Once B has done all the > needed EMODPR calls it would send the file descriptor to R. Even if R would > have full access to /dev/sgx_enclave, it would not matter, since B has done > EMODPR-EACCEPT dance with E. > > So what you can achieve with EMODPR is not protection against mistrusted > *OS*. There's absolutely no chance you could use it for that purpose > because mistrusted OS controls the whole process. > > EMODPR is to help to protect enclave against mistrusted *process*, i.e. > in the above scenario R. My suggestion for this is that let's make EMODPR either opt-in or opt-out with flags parameter, I don't care which way around. That way you can pick between performance or extra layer of hardening if you care about the above scenario. /Jarkko
