memfd_secret() in 5.14 [LWN.net]

memfd_secret() in 5.14

Posted Aug 9, 2021 15:12 UTC (Mon) by NYKevin (subscriber, #129325)
In reply to: memfd_secret() in 5.14 by jhoblitt
Parent article: memfd_secret() in 5.14

> Is it theoretically possible project process pages against a compromised kernel without hardware support?

*With* hardware support, you can use SGX or an equivalent technology. This sort of thing is increasingly available on consumer-grade hardware. But without hardware support, somebody has to have access to those pages (either the kernel or a hypervisor), because that's just The Way CPUs Work (TM). Of course, there's always the option of running on the bare metal with no kernel, but that's probably not what you had in mind.

to post comments

memfd_secret() in 5.14

Posted Aug 9, 2021 16:10 UTC (Mon) by jhoblitt (subscriber, #77733) [Link] (1 responses)

That is pretty much where I was going with the line of inquiry. If this is a security feature which is relatively easy to bypass, and there are by CPU instructions to create protected ephemeral memory regions (and TPMs to protect cryptographic keys at rest) how likely is it to see use in the wild?

memfd_secret() in 5.14

Posted Aug 10, 2021 8:53 UTC (Tue) by NYKevin (subscriber, #129325) [Link]

> which is relatively easy to bypass

Well... I don't know about that. You have to have arbitrary kernelspace code execution, which is supposed to be impossible even for root (assuming, for the sake of argument, that the kernel has been locked down and won't load arbitrary modules). If that is "relatively easy," then it means you have found a serious security vulnerability, regardless of whether memfd_secret() is in use or not, and regardless of whether the attacker is root or not.

In particular, this syscall defends against "simple" buffer overreads where the kernel is tricked into copying a bunch of random kernel-visible memory into an attacker-visible buffer, but without arbitrary code execution. That is also supposed to be impossible, of course, but constructing an overread attack is probably easier than constructing an ACE attack. In this sense, then, it can be thought of as a form of defense in depth, where we try to make attacks more difficult to construct, rather than trying to provide absolute guarantees of security.