memfd_secret() in 5.14 [LWN.net]

memfd_secret() in 5.14

Posted Aug 6, 2021 22:24 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
In reply to: memfd_secret() in 5.14 by mb
Parent article: memfd_secret() in 5.14

Crashing the app is fine. We can also do something like send a signal to prepare the app for impending shutdown and/or after the restore.

As a reaction, the application can re-obtain the secret from whence it came: security co-processor, web service, password prompt, etc.

to post comments

memfd_secret() in 5.14

Posted Aug 20, 2021 7:14 UTC (Fri) by ncm (guest, #165) [Link]

Far be it from me to agree with Cyberax, he is actually correct here. It is always permissible for an app to die while waking up from hibernation if its state cannot be restored and it cannot cope with that. I do not expect my ssh sessions to survive hibernation, and would expect ssh-agent to forget its keys.

If such an app has some way not to shut down, but to ask for its secrets to be restored instead, and continue, that might be better sometimes. But in no case does a need to clear secrets first mean hibernation must be disabled.

memfd_secret() in 5.14

Posted Aug 21, 2021 0:22 UTC (Sat) by alopatindev (guest, #153807) [Link] (3 responses)

> 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.

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?