{"id":1438,"date":"2020-09-02T16:22:25","date_gmt":"2020-09-02T23:22:25","guid":{"rendered":"https:\/\/outflux.net\/blog\/?p=1438"},"modified":"2022-04-04T14:08:00","modified_gmt":"2022-04-04T21:08:00","slug":"security-things-in-linux-v5-6","status":"publish","type":"post","link":"https:\/\/outflux.net\/blog\/archives\/2020\/09\/02\/security-things-in-linux-v5-6\/","title":{"rendered":"security things in Linux v5.6"},"content":{"rendered":"

Previously: v5.5<\/a>.<\/p>\n

Linux v5.6 was released back in March<\/a>. Here’s my quick summary of various features that caught my attention:<\/p>\n

WireGuard<\/strong>
\nThe widely used WireGuard VPN<\/a> has been out-of-tree for a very long time. After 3 1\/2 years since its initial upstream RFC<\/a>, Ard Biesheuvel and Jason Donenfeld finished the work getting all the crypto prerequisites sorted out<\/a> for the v5.5 kernel. For this release, Jason has gotten WireGuard itself landed<\/a>. It was a twisty road, and I’m grateful to everyone involved for sticking it out and navigating the compromises and alternative solutions.<\/p>\n

openat2()<\/code> syscall and RESOLVE_*<\/code> flags<\/strong>
\nAleksa Sarai has added a number of important path resolution “scoping” options to the kernel’s open()<\/code> handling, covering things like not walking above a specific point in a path hierarchy (RESOLVE_BENEATH<\/code><\/a>), disabling the resolution of various “magic links” (RESOLVE_NO_MAGICLINKS<\/code><\/a>) in procfs (e.g. \/proc\/$pid\/exe<\/code>) and other pseudo-filesystems, and treating a given lookup as happening relative to a different root directory (as if it were in a chroot, RESOLVE_IN_ROOT<\/code><\/a>). As part of this, it became clear that there wasn’t a way to correctly extend the existing openat()<\/code> syscall, so he added openat2()<\/code><\/a> (which is a good example of the efforts being made to codify “Extensible Syscall” arguments<\/a>). The RESOLVE_*<\/code> set of flags also cover prior behaviors like RESOLVE_NO_XDEV<\/code> and RESOLVE_NO_SYMLINKS<\/code>.<\/p>\n

pidfd_getfd()<\/code> syscall<\/strong>
\nIn the continuing growth of the much-needed pidfd APIs, Sargun Dhillon has added the pidfd_getfd()<\/code> syscall<\/a> which is a way to gain access to file descriptors of a process in a race-less way (or when \/proc<\/code> is not mounted). Before, it wasn’t always possible make sure that opening file descriptors via \/proc\/$pid\/fd\/$N<\/code> was actually going to be associated with the correct PID. Much more detail about this has been written up at LWN<\/a>.<\/p>\n

openat()<\/code> via io_uring<\/strong>
\nWith my “attack surface reduction” hat on, I remain personally suspicious of the io_uring()<\/code> family of APIs, but I can’t deny their utility for certain kinds of workloads. Being able to pipeline reads and writes without the overhead of actually making syscalls is pretty great for performance. Jens Axboe has added the IORING_OP_OPENAT command<\/a> so that existing io_urings can open files to be added on the fly to the mapping of available read\/write targets of a given io_uring. While LSMs are still happily able to intercept these actions, I remain wary of the growing “syscall multiplexer” that io_uring is becoming. I am, of course, glad to see that it has a comprehensive (if “out of tree”) test suite as part of liburing<\/code><\/a>.<\/p>\n

removal of blocking random pool<\/strong>
\nAfter making algorithmic changes to obviate separate entropy pools for random numbers, Andy Lutomirski removed the blocking random pool<\/a>. This simplifies the kernel pRNG code significantly without compromising the userspace interfaces designed to fetch “cryptographically secure” random numbers. To quote Andy, “This series should not break any existing programs. \/dev\/urandom<\/code> is unchanged. \/dev\/random<\/code> will still block just after booting, but it will block less than it used to.” See LWN for more details on the history and discussion of the series<\/a>.<\/p>\n

arm64 support for on-chip RNG<\/strong>
\nMark Brown added support for the future ARMv8.5’s RNG<\/a> (SYS_RNDR_EL0<\/code>), which is, from the kernel’s perspective, similar to x86’s RDRAND<\/code> instruction. This will provide a bootloader-independent way to add entropy to the kernel’s pRNG for early boot randomness (e.g. stack canary values, memory ASLR offsets, etc). Until folks are running on ARMv8.5 systems, they can continue to depend on the bootloader for randomness (via the UEFI RNG interface<\/a>) on arm64.<\/p>\n

arm64 E0PD<\/strong>
\nMark Brown added support for the future ARMv8.5’s E0PD feature<\/a> (TCR_E0PD1<\/code>), which causes all memory accesses from userspace into kernel space to fault in constant time. This is an attempt to remove any possible timing side-channel signals when probing kernel memory layout from userspace, as an alternative way to protect against Meltdown-style attacks. The expectation is that E0PD would be used instead of the more expensive Kernel Page Table Isolation (KPTI) features on arm64.<\/p>\n

powerpc32 VMAP_STACK<\/strong>
\nChristophe Leroy added VMAP_STACK support to powerpc32<\/a>, joining x86, arm64, and s390. This helps protect against the various classes of attacks that depend on exhausting the kernel stack in order to collide with neighboring kernel stacks. (Another common target, the sensitive thread_info<\/code>, had already been moved away from the bottom of the stack<\/a> by Christophe Leroy in Linux v5.1.)<\/p>\n

generic Page Table dumping<\/strong>
\nRelated to RISCV’s work to add page table dumping (via \/sys\/fs\/debug\/kernel_page_tables<\/code>), Steven Price extracted the existing implementations from multiple architectures and created a common page table dumping framework<\/a> (and then refactored all the other architectures to use it<\/a>). I’m delighted to have this because I still remember when not having a working page table dumper for ARM delayed me for a while when trying to implement upstream kernel memory protections there. Anything that makes it easier for architectures to get their kernel memory protection working correctly makes me happy.<\/p>\n

That’s in for now; let me know if there’s anything you think I missed. Next up: Linux v5.7<\/a>.<\/p>\n

© 2020 – 2022, Kees Cook<\/a>. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License<\/a>.
\"CC<\/a> <\/p>\n","protected":false},"excerpt":{"rendered":"

Previously: v5.5. Linux v5.6 was released back in March. Here’s my quick summary of various features that caught my attention: WireGuard The widely used WireGuard VPN has been out-of-tree for a very long time. After 3 1\/2 years since its initial upstream RFC, Ard Biesheuvel and Jason Donenfeld finished the work getting all the crypto […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,20,18,21,6,14,19],"tags":[],"_links":{"self":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/1438"}],"collection":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/comments?post=1438"}],"version-history":[{"count":17,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/1438\/revisions"}],"predecessor-version":[{"id":1571,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/1438\/revisions\/1571"}],"wp:attachment":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/media?parent=1438"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/categories?post=1438"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/tags?post=1438"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}