On Wed, Apr 08, 2020 at 07:56:36AM -0700, Sean Christopherson wrote: > On Wed, Apr 08, 2020 at 04:40:49PM +0300, Jarkko Sakkinen wrote: > > What starts to be obvious is that we don't do anything in code level > > in SGX particular but instead workaround something around /dev. > > Can you summarize the plan going forward? Thanks! Sure. The summary is that the permission problem should be solved outside of SGX. Doing an FS is somewhat big hammer to sort out the permission problem. It will also make configuration more clunky i.e. kernel defines some static permissions and then let say the systemd unit file will overwrite them with some other. It is somewhat more sound to have the udev db to contain the permissions. Admitting that we don't have exact solutions I think we have enough knowledge to say that things can be refined to work for SGX outside of SGX. I've been playing with the idea to add something like SB_I_DEVMMAPEXEC [1] to superblock flags. This would be set by devtmpfs (drivers/base/devtmpfs.c) initialization code. Then do_mmap_pgoff should check this flag from superblock and that we are mapping a device node. If these premises are fulfilled, then it would allow mmap(). This will make exec work when mapping device nodes but does not allow attacker to put executable to /dev and run them in the threat scenario described by Topi [2]. Andy also mentioned that he was going mail to udev ML but have not checked that at this point. [1] For explicit control of this new behavior also mnt flag is needed. [2] https://patchwork.kernel.org/patch/11467637/#23269417 /Jarkko
