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
