On Tue, Apr 07, 2020 at 10:54:46PM +0300, Topi Miettinen wrote: > On 7.4.2020 21.04, Jarkko Sakkinen wrote: > > 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? > > It seems to be just a regular tmpfs but with direct access to add device > nodes when drivers are loaded. Nice idea, maybe something like that could be > done with SELinux policy. Anyway, thank you for all the feedback. What starts to be obvious is that we don't do anything in code level in SGX particular but instead workaround something around /dev. /Jarkko
