Hi Jarkko, On 1/17/2022 6:22 PM, Jarkko Sakkinen wrote: > On Tue, Jan 18, 2022 at 03:59:29AM +0200, Jarkko Sakkinen wrote: >> On Mon, Jan 17, 2022 at 08:13:32AM -0500, Nathaniel McCallum wrote: >>> On Sat, Jan 15, 2022 at 6:57 AM Jarkko Sakkinen <jarkko@xxxxxxxxxx> 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. >>> >>> There are two general cases that I can see. Both are valid. >>> >>> 1. The OS moves from a trusted to an untrusted state. This could be >>> the multi-process system you've described. But it could also be that >>> the kernel becomes compromised after the enclave is fully initialized. >>> >>> 2. The OS is untrustworthy from the start. >>> >>> The second case is the stronger one and if you can solve it, the first >>> one is solved implicitly. And our end goal is that if the OS does >>> anything malicious we will crash in a controlled way. >>> >>> A defensive enclave will always want to have the least number of >>> privileges for the maximum protection. Therefore, the enclave will >>> want the OS to call EMODPR. If that were it, the host could just lie. >>> But the enclave also verifies that the EMODPR operation was, in fact, >>> executed by doing EACCEPT. When the enclave calls EACCEPT, if the >>> kernel hasn't restricted permissions then we get a controlled crash. >>> Therefore, we have solved the second case. >> >> So you're referring to this part of the SDM pseude code in the SDM: >> >> (* Check the destination EPC page for concurrency *) >> IF ( EPC page in use ) >> THEN #GP(0); FI; >> >> I wonder does "EPC page in use" unconditionally trigger when EACCEPT >> is invoked for a page for which all of these conditions hold: >> >> - .PR := 0 (no EMODPR in progress) >> - .MODIFIED := 0 (no EMODT in progress) >> - .PENDING := 0 (no EMODPR in progress) >> >> I don't know the exact scope and scale of "EPC page in use". >> >> Then, yes, EACCEPT could be at least used to validate that one of the >> three operations above was requested. However, enclave thread cannot say >> which one was it, so it is guesswork. > > OK, I got it, and this last paragraph is not true. SECINFO given EACCEPT > will lock in rest of the details and make the operation deterministic. Indeed - so the SDM pseudo code that is relevant here can be found under the "(* Verify that accept request matches current EPC page settings *)" comment where the enclave can verify that all EPCM values are as they should and would fail with SGX_PAGE_ATTRIBUTES_MISMATCH if there is anything amiss. > > The only question mark then is the condition when no requests are active. Could you please elaborate what you mean with this question? If no request is active then I understand that to mean that no request has started. Reinette
