
Keeping secrets in memfd areas - Tomte
https://lwn.net/SubscriberLink/812325/b642e849751b9068/
======
jart
Didn't Intel try to do just that, with SGX enclaves, and it still got hacked?
If Intel couldn't do it for just one architecture, then I can't see the
promise of a portable "generalized" system call panning out.

There isn't much empirical evidence that some of these open source memory
obfuscation techniques provide users much benefit from external attackers. It
feels more like DRM that makes it nearly impossible for us to trace or examine
what these open source binaries we're trusting from internet people are
actually doing. The GPL forbids that.

memfd_create is also one of those wat kind of system calls, which initially
don't appear to enable any use case that couldn't be accomplished by other
means, e.g. open+mmap+unlink+close, which posix specifies won't delete the
mapping, and the performance of Linux at managing virtual pages in memory is
outstanding.

~~~
bkor
> memfd_create is also one of those wat kind of system calls, which initially
> don't appear to enable any use case that couldn't be accomplished by other
> means

The author agrees with that. It's just a bit simpler. See e.g.
[https://dvdhrm.wordpress.com/tag/memfd/](https://dvdhrm.wordpress.com/tag/memfd/)

The benefits of the system call according to above link are:

1) memfd_create does not require a local mount-point

2) There are no name-clashes and no global registry

3) the code required for memfd_create is 100 lines

4) sealing

