memfd_secret() in 5.14 [LWN.net]

memfd_secret() in 5.14

Posted Aug 6, 2021 17:07 UTC (Fri) by mb (subscriber, #50428)
In reply to: memfd_secret() in 5.14 by ericonr
Parent article: memfd_secret() in 5.14

It's a nice idea to have such secret memory where applications (e.g. browsers) can store sensitive data.
But if that feature breaks hibernation, I don't see how distributions could enable it by default. It will never experience widespread use then, even if most users don't actually use hibernation.

If the hibernation image is encrypted, then I don't see why memfd_secret() should disable hibernation.

to post comments

memfd_secret() in 5.14

Posted Aug 7, 2021 0:34 UTC (Sat) by ericonr (guest, #151527) [Link] (6 responses)

Well, the article mentions hiding things even from the kernel. Hibernation would break that neatly. Someone with a local account could probably run `systemctl hibernate`, and try to obtain the secret some time after the kernel remaps that piece of memory via a local kernel exploit.

memfd_secret() in 5.14

Posted Aug 7, 2021 6:29 UTC (Sat) by mb (subscriber, #50428) [Link] (1 responses)

>and try to obtain the secret some time after the kernel remaps that piece of memory via a local >kernel exploit.

Yes, well. But only during the memory restore time window. After that the kernel would hopefully remove the pages from its mapping again.

But is memfd_secret() safe against kernel level privilege escalations anyway?
Why couldn't an attacker inject code to remap the areas?
So if you gain random code execution rights in the kernel, it's game over. With and without hibernation.

memfd_secret() in 5.14

Posted Aug 7, 2021 7:16 UTC (Sat) by david.hildenbrand (subscriber, #108299) [Link]

I was told that even exposing secretmem pages for a very short time in the direct map, for example when hibernating, is a security risk. As one example. other CPUs could expose that data.

It‘s the same reasoning that blocks these pages to be movable: migration code would have to temporarily map them. One approach discussed is using temporary per-cpu page tables for page migration.

memfd_secret() in 5.14

Posted Aug 7, 2021 7:23 UTC (Sat) by david.hildenbrand (subscriber, #108299) [Link] (3 responses)

I‘d like to note that secretmem does not protect against kernel exploits or against root in most setups getting hold of that data. Once you‘re already in the kernel, you might just be able to remap the pages. Once you‘re root, you can trigger kexec or kdump to expose the data. Further, if all memory isn‘t getting cleared during reboot (e.g., in most VMs) you might be able to reboot and extract that data.

memfd_secret() in 5.14

Posted Aug 7, 2021 8:10 UTC (Sat) by randomguy3 (subscriber, #71063) [Link] (2 responses)

Which leads me to wonder: what does it protect against?

memfd_secret() in 5.14

Posted Aug 7, 2021 10:59 UTC (Sat) by david.hildenbrand (subscriber, #108299) [Link]

IIUC, the „easy“ ways to access this data (/proc/kcore), application BUGs (e.g., accidentally using the secretmem area as a sending buffer) and kernel/CPU BUGs. When disabling other features (e.g., kdump) and extending other features (e.g., clearing all secretmem areas before kexec or before reboots) we can make it even harder for root to still read secretmem in the future. But it might be hard to get rid of all (kdb?) such ways for root to still read that memory.

memfd_secret() in 5.14

Posted Aug 9, 2021 12:59 UTC (Mon) by hkario (subscriber, #94864) [Link]

application bugs: you can't use that memory in syscalls