On Tue, Apr 07, 2020 at 07:59:00PM +0300, Jarkko Sakkinen wrote: > On Tue, Apr 07, 2020 at 07:57:08PM +0300, Jarkko Sakkinen wrote: > > On Tue, Apr 07, 2020 at 12:04:58PM +0300, Topi Miettinen wrote: > > > Please correct me if I'm wrong, but isn't it the goal of SGX to let a > > > (suitably privileged) process designate some of its memory areas as part of > > > SGX enclave? If so, why don't you simply add a system call to do so, such as > > > > > > int sgx_mprotect(void *start, size_t length, int prot, u64 sgx_flags); > > > > > > like existing pkey_mprotect()? Or add a flag PROT_SGX to mprotect() like > > > existing PROT_SAO/PROT_SEM? > > > > > > -Topi > > > > New syscalls is always the last resort path, especially if they are > > associated with an arch. > > > > PROT_SGX sounds something worth of consideration. > > > > Another idea to throw would be noexec_dev mount option that would allow > > exec *only* for the device nodes (zero analysis done on feasibility). > > The 2nd proposal has the merit that it would scale above SGX and > does not give additional strengths to the adversary in the context > of the threat scenario. Or. Why couldn't kernel just disallow anything but device files to be created to devtmpfs unconditionally? Then noexec would not be needed in the first place. /Jarkko
