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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Also, I think we need a changelog message or, even better, actual docs in kernel, explaining the actual final set of rules and invariants for all these masks.

--Andy



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux