On Mon, Jul 08, 2019 at 06:23:46PM +0300, Jarkko Sakkinen wrote: > On Sun, 2019-07-07 at 12:08 -0700, Sean Christopherson wrote: > > LGTM but why it isn't like: > > > > > > __u16 mrmask; > > > __u8 prot; > > > __u8 reserved[5]; > > > > Because math is hard :-) Though I think we'd want > > > > __u16 mrmask > > __u8 prot > > __u8 pad[5]; > > > > with an optional > > > > __u64 reserved[?]; > > > > "pad" can be ignored, e.g. doesn't need to be explicitly zeroed by > > userspace, whereas "reserved" requires explicit zeroing and probably an > > associated kernel check. > > OK, cool with the change itself. Still need to get a better idea > how these make sense in architectural sense. > > Things that would help with overall picture: > > 1. We have to figure out how this can be useful when LSM's are not used. Declaring PROT_EXEC is useful to enforce noexec filesystems. Beyond that, I am not aware of any meaningful use case. > That gives at least some evidence that the security model is overally > good if it makes sense with and without LSM. Right now this looks like > dead functionality if not coupled with an LSM. I agree that it's effectively dead functionality without LSMs, but keep in mind that this LSM rat hole was opened specifically because SGX could be used to circumvent existing LSM security policies. In other words, the purpose of the UAPI extension is to achieve LSM compatibility without incurring significant complexity in the LSM subsystem. > 2. Probably some "user story" type of examples would help with the > discussion overall [1] i.e. how one would use this for > her own good. The compelling story is Andy's original concern that userspace could circumvent existing security policies by running code in an enclave. AIUI, closing the LSM loophole is the minimal requirement to get SGX upstreamed. The extensive discussion has largely been focused on ensuring that whatever mechanism is used to close the loophole will play nice with future SGX functionality and/or LSM security policies. > [1] Probably many of the folks who work x86 tree have ignored major > part of the discussion. Somehow these should be brought to > nutshell so that anyone can get whatever the model is. Anyone > should get it basically. > > /Jarkko >
