6 ms·

The memfd_secret() system call is pretty exciting (https://lwn.net/Articles/836724/ https://lwn.net/Articles/836724/). Once the secretmem feature is enabled at

by tim-- 5y ago

The memfd_secret() system call is pretty exciting (https://lwn.net/Articles/836724/ https://lwn.net/Articles/836724/). Once the secretmem feature is enabled at boot time, you are hardened against kernel flaws. A userspace process (running with elevated privileges) will only be able to perform secrets exfiltration using ptrace. A better source for these changes are the two merge window roundups from LWN: - https://lwn.net/Articles/861248/ https://lwn.net/Articles/861248/ - https://lwn.net/Articles/861695/ https://lwn.net/Articles/861695/

Retr0id 5y ago
It's worth noting that it isn't a magic bullet - it only hardens against certain classes of kernel flaw. If the kernel is compromised, it is trivial to extract the secrets (this may seem obvious, but the strength of the feature has been over-hyped by some publications) https://github.com/JonathonReinhart/nosecmem https://github.com/JonathonReinhart/nosecmem
- tedunangst 5y ago
  Yeah, I'm kinda unclear on exactly what it prevents. Shouldn't the kernel, if not compromised, be preventing these mappings anyway?
  - geofft 5y ago
    Linux has a "direct map" of all physical memory in kernelspace, which I guess makes things easier. See https://www.kernel.org/doc/Documentation/x86/x86_64/mm.txt https://www.kernel.org/doc/Documentation/x86/x86_64/mm.txt "direct mapping of all physical memory (page_offset_base)". (I think this is not uncommon: JOS, which my undergrad operating systems class used, does this.) Memory allocated with memfd_secret gets removed from the direct map, which means that from any other process's address space, there is no virtual address (regardless of memory protection) that corresponds to those physical addresses. So any exploit that gets only gets you memory read/write but not kernelspace code execution (various types of wild pointers, etc., as well as whatever exciting speculative execution vulnerability will undoubtedly show up next year) cannot compromise the data in a memfd_secret mapping.
    - rfoo 5y ago
      > any exploit that gets only gets you memory read/write but not kernelspace code execution That's an odd assumption. There are still a lot of universal tricks for turning a truly arbitrary R/W primitive into code execution, e.g. just write to the page table. OTOH, this does guard against arbitrary read primitives, which, as you mentioned, is especially useful in post-Spectre days.
    - tedunangst 5y ago
      Ah, okay. I get it. There has been some loose talk to reduce the amount of memory mapped in the direct map for openbsd.
  - Retr0id 5y ago
    I'm speculating a bit here, but I think it could guard against side-channel attacks against the kernel. e.g. if you had a sidechannel that leaks data from the kernel, the kernel can't disclose data that it can't actually read.
- ggm 5y ago
  Attacks on s/w and h/w systems are asymmetric warfare. Until the ptrace or other attacks are scripted, the barrier to entry is usefully high. Once they are scripted, it can be close to zero, depending. OTOH if the ptrace and other approaches leave a signature, then you remain at risk but able to know. And, it has wheel-of-life qualities as your attacker codes to hide the signature, you code to keep the visibility open, and to try and defeat the underlying attack. And so it goes.

by tim-- 5y ago

Retr0id 5y ago

It's worth noting that it isn't a magic bullet - it only hardens against certain classes of kernel flaw. If the kernel is compromised, it is trivial to extract the secrets (this may seem obvious, but the strength of the feature has been over-hyped by some publications) https://github.com/JonathonReinhart/nosecmem https://github.com/JonathonReinhart/nosecmem

tedunangst 5y ago
Yeah, I'm kinda unclear on exactly what it prevents. Shouldn't the kernel, if not compromised, be preventing these mappings anyway?
- geofft 5y ago
  Linux has a "direct map" of all physical memory in kernelspace, which I guess makes things easier. See https://www.kernel.org/doc/Documentation/x86/x86_64/mm.txt https://www.kernel.org/doc/Documentation/x86/x86_64/mm.txt "direct mapping of all physical memory (page_offset_base)". (I think this is not uncommon: JOS, which my undergrad operating systems class used, does this.) Memory allocated with memfd_secret gets removed from the direct map, which means that from any other process's address space, there is no virtual address (regardless of memory protection) that corresponds to those physical addresses. So any exploit that gets only gets you memory read/write but not kernelspace code execution (various types of wild pointers, etc., as well as whatever exciting speculative execution vulnerability will undoubtedly show up next year) cannot compromise the data in a memfd_secret mapping.
  - rfoo 5y ago
    > any exploit that gets only gets you memory read/write but not kernelspace code execution That's an odd assumption. There are still a lot of universal tricks for turning a truly arbitrary R/W primitive into code execution, e.g. just write to the page table. OTOH, this does guard against arbitrary read primitives, which, as you mentioned, is especially useful in post-Spectre days.
  - tedunangst 5y ago
    Ah, okay. I get it. There has been some loose talk to reduce the amount of memory mapped in the direct map for openbsd.
- Retr0id 5y ago
  I'm speculating a bit here, but I think it could guard against side-channel attacks against the kernel. e.g. if you had a sidechannel that leaks data from the kernel, the kernel can't disclose data that it can't actually read.
ggm 5y ago
Attacks on s/w and h/w systems are asymmetric warfare. Until the ptrace or other attacks are scripted, the barrier to entry is usefully high. Once they are scripted, it can be close to zero, depending. OTOH if the ptrace and other approaches leave a signature, then you remain at risk but able to know. And, it has wheel-of-life qualities as your attacker codes to hide the signature, you code to keep the visibility open, and to try and defeat the underlying attack. And so it goes.