I have pretty much figured out how to change the driver implementation
from VMA based to file based. Most of the code in the driver can be
reused with not that enormous changes. I think it is a clue that the
architecture is somewhat right because changing the driver this
radically does not seem to require any changes to the core.

Using anon inode is the right choice because it is more robust interface
to be able to create multiple enclaves.

The only remaining open that I have when it comes to implementing this
is the backing storage. From API perspective the most robust choice
would be to revert to use shmem file. It would be easy then to create a
complete construction flow without any dependencies to mm_struct.

I do recognize the issue with accounting but to which process the
backing storage should be accounted anyway in this new paradigm.

I've attached the new uapi header to this email that I'm going forward
with.

/Jarkko