memfd_secret() in 5.14 [LWN.net]

memfd_secret() in 5.14

Posted Aug 9, 2021 21:33 UTC (Mon) by jhoblitt (subscriber, #77733)
In reply to: memfd_secret() in 5.14 by khim
Parent article: memfd_secret() in 5.14

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?

to post comments

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.