On Mon, Apr 6, 2020 at 2:24 PM Jarkko Sakkinen
<jarkko.sakkinen@xxxxxxxxxxxxxxx> 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.
I think the best bet is for you to ignore this and let userspace figure it out.
