memfd_secret() in 5.14 [LWN.net]

memfd_secret() in 5.14

Posted Aug 21, 2021 0:22 UTC (Sat) by alopatindev (guest, #153807)
In reply to: memfd_secret() in 5.14 by Cyberax
Parent article: memfd_secret() in 5.14

> send a signal to prepare the app for impending shutdown and/or after the restore

I like this idea. I wonder how multithreaded app should handle this signal though. Which thread is supposed to handle the signal: the main one, the random one, all of them?

Another question: do I understand correctly that the protected memory can't even be written to swap in case if the system is about to run OOM? (Or else I guess it would not make much sense to disable just hibernation, without disabling ordinary swapping).

And another completely unrelated idea: how about (at least optionally) zeroing protected memory (by kernel) before completely releasing it? I know that apps suppose to do that, but it's so easy to implement it incorrectly, that I personally would be happy if kernel simply would not allow to leak incorrectly released memory with sensitive data.

to post comments

memfd_secret() in 5.14

Posted Aug 21, 2021 1:17 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> I like this idea. I wonder how multithreaded app should handle this signal though. Which thread is supposed to handle the signal: the main one, the random one, all of them?

Typically in a multithreaded app you will have a slim signal handler that sets some kind of a global flag that is processed "soon" by whatever thread that cares about it.

> Another question: do I understand correctly that the protected memory can't even be written to swap in case if the system is about to run OOM? (Or else I guess it would not make much sense to disable just hibernation, without disabling ordinary swapping).

Protected memory is realistically going to be used for stuff like encryption keys, so it's unlikely that it's going to make any measurable impact on OOM.

memfd_secret() in 5.14

Posted Aug 21, 2021 13:44 UTC (Sat) by alopatindev (guest, #153807) [Link]

> Protected memory is realistically going to be used for stuff like encryption keys, so it's unlikely that it's going to make any measurable impact on OOM.

I was thinking the same, thanks for clarification!

> Typically in a multithreaded app you will have a slim signal handler that sets some kind of a global flag that is processed "soon" by whatever thread that cares about it.

Cool but I worry about this "soon". Are there any risks for (multithreaded) app devs with this solution, that they might run into some stability issues that are hard to debug?

How about this approach:
- add some flag (or more likely some sync primitive) in the kernel that allows reading/writing to the protected memory by a process (the flag is controlled by some additional syscall for instance)
- when the flag is set — the kernel is disallowed to hibernate (the hibernation will be postponed until all such flags are reset)
- when the flag is reset — the app is disallowed to write to the protected memory (it will always get SIGBUS in this case)
- when all the flags are reset by all processes and the hibernation is started, since the processes are suspended, all the protected memories become allowed to be written by the kernel (but not to be read!), the memories will be zeroed out (by the kernel) and released and the flags will no longer be allowed to set (syscall will return error)
- as soon as apps wake up and they try to set the flag — they get errors, so they fully release the protected memory and call memfd_secret again.

Perhaps this would solve this hibernation without sacrificing security and apps stability at the same time?

What do you think: is that feasible and will it really improve anything for app devs? Thanks.

memfd_secret() in 5.14

Posted Aug 22, 2021 11:28 UTC (Sun) by alopatindev (guest, #153807) [Link]

I'll clarify what I mean by potential "stability issues" in case of implementing the signalling idea: suppose that process reads the global flag and acknowledges that it can read/write the protected memory. But just before it starts reading/writing, the flag gets updated and now the process crashes after attempting to read/write.

I guess there's no way to guarantee process stability with this design. Is that right?