And when would you want to do that ? Really curious as I fail to see a usecase where the same goal could not be achieve otherwise. But there must be some otherwise the API would not have been introduced i guess.
> otherwise the API would not have been introduced
I don't think memfd_create was added specifically for the purpose of running binaries from memory; it's more generally useful in cases where you want a memory-backed file but don't want to rely on the presence of a memory-backed filesystem (tmpfs). Many programs create a file in a well-known tmpfs like /dev/shm then delete it, but memfd_create is a more sensible solution if you don't want to share memory via the filesystem. memfd_create eliminates concerns over naming and collisions.
Security issues aside, I can imagine maintaining compiled code for stored procedures in database BLOBs.
Similarly, in an appropriate trust environment, I might want to ship work units to remote machines in the form of raw ELF. Copying the bits to disk just to execute them is unneeded overhead.
I wonder if there's a way to execute from mlock'd or madvised memory. I can imagine this be particularly useful, if you wanted to prevent your injected program (malware? valuable IP?) from being written to disk or appearing in a core dump.
The memfd api has lots of other uses, the fact you can exec is just a byproduct.
It is in fact silly since write and execute are orthogonal. You can mount a filesystem as noexec. Although memfd does put a bullet into W^X aspirations.