memfd_secret() in 5.14 [LWN.net]

memfd_secret() in 5.14

Posted Aug 7, 2021 14:26 UTC (Sat) by jhoblitt (subscriber, #77733)
Parent article: memfd_secret() in 5.14

I'm not clear as to what type of threat this feature is designed to protect against. What is the threat model? It doesn't sound like it protects against CPU side channel attacks. Presumably, a compromised kernel would allow the pages to be simply remapped. The data is in ram, various levels of caches and exposed on buses so it doesn't defend against physical hardware/firmware compromise. Are memfd regions included in core dumps? I suppose it could prevent data from disclosure via kernel information leaks? I do not understand how page mapping works in a VM guest kernel but I'm guessing this doesn't help protect memory against a compromised VMM either? Are there any known kernel vulnerabilities that allowed reading of memory this feature would have mitigated?

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

to post comments

memfd_secret() in 5.14

Posted Aug 7, 2021 15:54 UTC (Sat) by khim (subscriber, #9252) [Link] (2 responses)

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

You certainly can do that on a system with a hypervisor (although would need some cooperation with said hypervisor).

memfd_secret() in 5.14

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

In the case of a guest kernel, it isn't surprising if the host kernel provided protection features, but I think it is likely theoretically impossible to protect processes within a guest against the compromise of the host kernel without special hardware support that protects the guest kernel memory itself against the host kernel.

memfd_secret() in 5.14

Posted Aug 9, 2021 20:57 UTC (Mon) by khim (subscriber, #9252) [Link]

That special hardware, though, may be yet another hypervisor. Although not sure how feasible that would be, but the idea sounds interesting: essentially a microkernel which is basically does MMU and IOMMU — and that's it.

memfd_secret() in 5.14

Posted Aug 9, 2021 11:03 UTC (Mon) by sandsmark (guest, #62172) [Link] (8 responses)

I just assumed it was for DRM purposes (the Netflix type).

I. e. try to stop the user from inspecting the code running running on their machine (for example the Widevine module loaded in Firefox or Chrome).

memfd_secret() in 5.14

Posted Aug 9, 2021 20:59 UTC (Mon) by khim (subscriber, #9252) [Link] (7 responses)

Use it for DRM is complete no-brainer and you can be 100% sure it would be, eventually, used for that.

But I don't think it's just DRM, there are more interesting applications if you consider hypervisors, at least.

memfd_secret() in 5.14

Posted Aug 9, 2021 21:06 UTC (Mon) by jhoblitt (subscriber, #77733) [Link] (6 responses)

Who would use it for DRM? Android? Something like Widevine couldn't require it until something like a decade from now. rhel7/centos7, which is still widely deployed on business workstations, is using a kernel from 2013.

memfd_secret() in 5.14

Posted Aug 9, 2021 21:19 UTC (Mon) by khim (subscriber, #9252) [Link] (5 responses)

> Something like Widevine couldn't require it until something like a decade from now.

Why? When Android and ChromeOS would be updated it can use it. Android usually takes longer, but not decade, more like 1-2 years.

The fact that this may break someone on desktop Linux is not a big deal for Google: Linux users are not their primary customers (e.g. Google Drive still have no Linux client).

Also: remember that Widevine is not-all-or-nothing: there are three levels of support. Would be easy to push devices without memfd_secret into tier2 or 3.

> rhel7/centos7, which is still widely deployed on business workstations, is using a kernel from 2013.

Not even close. If you would look on just a version number, then RHEL uses ancient kernel, but if you look on the list of features it supports… it carries tons of stuff backported from “latest and greatest”. If memfd_secret would be useful it will be backported, too, no problem.

memfd_secret() in 5.14

Posted Aug 9, 2021 21:33 UTC (Mon) by jhoblitt (subscriber, #77733) [Link] (4 responses)

I'm not seeing a compelling use case for a feature that doesn't really provide much security... especially for the DRM use case where the administrator of the system is probably considered the primary threat.

In particular, android already has keystore (which supports TEE). Why would android apps bother to support a feature which will not be supported on the majority of devices for years (~1/2 of the android population is still <= 9) and provides inferior security to an already universal feature (since 4) which takes advantage of hardware isolation where supported?

memfd_secret() in 5.14

Posted Aug 9, 2021 21:41 UTC (Mon) by khim (subscriber, #9252) [Link] (2 responses)

> Because existing feature doesn't provide the same level of protection?

Keystore does offer certain protections and may, probably, make sure you can't talk to Netflix directly, but it can not ensure that uncompressed video wouldn't be accessible to the rest of the system. memfd_secret can offer such ability.

And widevine doesn't come with apps in Android world, rather, it's something your device vendor provides. Thus the fact that old devices don't have it is not a big deal — very often they don't have the means to play 4K HDR video anyway, thus can safely be demoted to tier 2 or 3.

memfd_secret() in 5.14

Posted Aug 9, 2021 22:18 UTC (Mon) by excors (subscriber, #95769) [Link]

> Keystore does offer certain protections and may, probably, make sure you can't talk to Netflix directly, but it can not ensure that uncompressed video wouldn't be accessible to the rest of the system. memfd_secret can offer such ability.

The TEE can (and does) do that - the decrypted bitstream and the decoded pixels are stored in RAM that's made inaccessible to the kernel, and the GPU won't render those pixels onto a kernel-accessible buffer or send them to a display that's not protected by HDCP etc. Since that hardware support already exists and seems to be quite widespread on Android, it would be a step backwards to start relying on the kernel to enforce the security boundary.

memfd_secret() in 5.14

Posted Aug 9, 2021 23:18 UTC (Mon) by jhoblitt (subscriber, #77733) [Link]

`memfd_secret()` seems to be trying to do the impossible and project the memory of a process from the kernel in software. It is not a replacement for a TEE but in fairness would be much easier to use. For the specific case of DRM, which is trying allow a 3rd party to restrict the functionality of an end-users device to prevent copying, it is completely unsuitable. (This is also ignoring the fundamental flaw of DRM in that data has be unencrypted somewhere to be displayed and will always be vulnerable to copying.) A loadable module should be able to find and remap the pages to allow them to be dumped. The system call could equally be modified to copy the data or simply remap it to `memfd_create()`.

DRM isn't a use case I think the kernel should bother to accommodate. I'm much more interested in functionality that protects "my" private keys. A good test would be how is luks, gpg/gpg-agent, ssh-agent, openssl, etc. going to use this?

memfd_secret() in 5.14

Posted Aug 10, 2021 0:47 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

It'll be useful for VPN session keys, access tokens for hardware TPMs, session cookies for sudo and other similar ephemeral but important credentials.

memfd_secret() in 5.14

Posted Aug 9, 2021 15:12 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (2 responses)

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

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.