memfd_secret() in 5.14 [LWN.net]

memfd_secret() in 5.14

Posted Aug 9, 2021 20:59 UTC (Mon) by khim (subscriber, #9252)
In reply to: memfd_secret() in 5.14 by sandsmark
Parent article: memfd_secret() in 5.14

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.

to post comments

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.