On 2020-04-07 01:18, Andy Lutomirski wrote: > On Mon, Apr 6, 2020 at 2:24 PM Jarkko Sakkinen > wrote: >> >> On Mon, Apr 06, 2020 at 12:53:41PM -0700, Andy Lutomirski wrote: >>>> sgxfs is somewhat trivial to implement and has one stakeholder less to >>>> worry about. It is not really a huge stretch. >>>> >>>> Overally, I think it is something that we could live with. At least it >>>> is something that does not step on others toes. >>>> >>>> Haitao: If we go with sgxfs route, then you can for the moment do what >>>> Andy suggested: bind mount it to /dev/sgx. >>> >>> That also needs userspace support. >>> >>> I’ll start a thread on the udev list. >> >> Haven't written any code yet but just by drafting the idea I already >> pinpointed something. >> >> You would add roughly this to the existing codebase: >> >> * struct file_system_type sgxfs >> * struct fs_context_operations sgxfs_ctx_ops >> * int sgxfs_get_tree() >> * int sgxfs_fill_super() >> * const struct tree_descr sgxfs_files[] >> >> The files would be defined as like this: >> >> static const struct tree_descr sgxfs_files[] { >> [SGXFS_ENCLAVE] = { "enclave", &sgxfs_encl_ops, /* ? */ }, >> [SGXFS_PROVISION] = { "provision", &sgxfs_encl_ops, /* ? */ }, >> }; >> >> The permissions would need to be completely static, which feels nasty >> from maintainability viewpoint :-( And I see no gain anywhere. >> >> In my opinion udev defining the whole /dev as noexec has zero technical >> merits. It is same as they would say that "we don't trust our own >> database". There are no real security benefits as long as dev nodes are >> configured correctly. > > I tend to agree, but it could be seen as a sort-of-valid hardening measure. Yeah it seems to me `noexec` is overly broad in not allowing mmap(PROT_EXEC). I'd expect it to disallow only execve(), which is fine for /dev. -- Jethro Beekman | Fortanix