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.
/Jarkko
