{"id":1311,"date":"2019-07-17T17:07:36","date_gmt":"2019-07-18T00:07:36","guid":{"rendered":"https:\/\/outflux.net\/blog\/?p=1311"},"modified":"2022-05-05T20:30:44","modified_gmt":"2022-05-06T03:30:44","slug":"security-things-in-linux-v5-2","status":"publish","type":"post","link":"https:\/\/outflux.net\/blog\/archives\/2019\/07\/17\/security-things-in-linux-v5-2\/","title":{"rendered":"security things in Linux v5.2"},"content":{"rendered":"

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

Linux kernel v5.2 was released<\/a> last week! Here are some security-related things I found interesting:<\/p>\n

page allocator freelist randomization<\/strong>
\nWhile the SLUB and SLAB allocator freelists have been randomized for a while now<\/a>, the overarching page allocator itself wasn’t. This meant that anything doing allocation outside of the kmem_cache<\/code>\/kmalloc()<\/code> would have deterministic placement in memory. This is bad both for security and for some cache management cases. Dan Williams implemented this randomization under CONFIG_SHUFFLE_PAGE_ALLOCATOR<\/a> now, which provides additional uncertainty to memory layouts, though at a rather low granularity of 4MB (see SHUFFLE_ORDER<\/code>). Also note that this feature needs to be enabled at boot time with page_alloc.shuffle=1<\/code> unless you have direct-mapped memory-side-cache (you can check the state at \/sys\/module\/page_alloc\/parameters\/shuffle<\/code>).<\/p>\n

stack variable initialization with Clang<\/strong>
\nAlexander Potapenko added support via CONFIG_INIT_STACK_ALL<\/a> for Clang’s -ftrivial-auto-var-init=pattern<\/code> option that enables automatic initialization of stack variables<\/a>. This provides even greater coverage than the prior GCC plugin for stack variable initialization<\/a>, as Clang’s implementation also covers variables not passed by reference. (In theory, the kernel build should still warn about these instances, but even if they exist, Clang will initialize them.) Another notable difference between the GCC plugins and Clang’s implementation is that Clang initializes with a repeating 0xAA byte pattern, rather than zero. (Though this changes under certain situations, like for 32-bit pointers which are initialized with 0x000000AA.) As with the GCC plugin, the benefit is that the entire class of uninitialized stack variable flaws goes away.<\/p>\n

Kernel Userspace Access Prevention on powerpc<\/strong>
\nLike SMAP on x86 and PAN on ARM, Michael Ellerman and Russell Currey have landed support for disallowing access to userspace without explicit markings in the kernel (KUAP) on Power9<\/a> and later PPC CPUs under CONFIG_PPC_RADIX_MMU=y<\/code> (which is the default). This is the continuation of the execute protection (KUEP) in v4.10<\/a>. Now if an attacker tries to trick the kernel into any kind of unexpected access from userspace (not just executing code), the kernel will fault.<\/p>\n

Microarchitectural Data Sampling mitigations on x86<\/strong>
\nAnother set of cache memory side-channel attacks came to light, and were consolidated together under the name Microarchitectural Data Sampling<\/a> (MDS). MDS is weaker than other cache side-channels (less control over target address), but memory contents can still be exposed. Much like L1TF<\/a>, when one’s threat model includes untrusted code running under Symmetric Multi Threading (SMT: more logical cores than physical cores), the only full mitigation is to disable hyperthreading (boot with “nosmt<\/code>“). For all the other variations of the MDS family, Andi Kleen (and others) implemented various flushing mechanisms<\/a> to avoid cache leakage.<\/p>\n

unprivileged userfaultfd sysctl knob<\/strong>
\nBoth FUSE and userfaultfd provide attackers with a way to stall a kernel thread in the middle of memory accesses from userspace by initiating an access on an unmapped page. While FUSE is usually behind some kind of access controls, userfaultfd hadn’t been. To avoid various heap grooming<\/a> and heap spraying<\/a> techniques for exploiting Use-after-Free flaws, Peter Xu added the new “vm.unprivileged_userfaultfd<\/a><\/code>” sysctl knob to disallow unprivileged access to the userfaultfd syscall.<\/p>\n

temporary mm for text poking on x86<\/strong>
\nThe kernel regularly performs self-modification with things like text_poke()<\/code> (during stuff like alternatives, ftrace, etc). Before, this was done with fixed mappings (“fixmap”) where a specific fixed address at the high end of memory was used to map physical pages as needed. However, this resulted in some temporal risks: other CPUs could write to the fixmap, or there might be stale TLB entries on removal that other CPUs might still be able to write through to change the target contents. Instead, Nadav Amit has created a separate memory map for kernel text writes<\/a>, as if the kernel is trying to make writes to userspace. This mapping ends up staying local to the current CPU, and the poking address is randomized<\/a>, unlike the old fixmap.<\/p>\n

ongoing: implicit fall-through removal<\/strong>
\nGustavo A. R. Silva is nearly done with marking<\/a> (and fixing<\/a>) all the implicit fall-through cases<\/a> in the kernel. Based on the pull request from Gustavo<\/a>, it looks very much like v5.3 will see -Wimplicit-fallthrough<\/code> added to the global build flags and then this class of bug should stay extinct in the kernel.<\/p>\n

CLONE_PIDFD added<\/strong>
\nChristian Brauner added the new CLONE_PIDFD<\/code> flag<\/a> to the clone()<\/code> system call, which complements the pidfd work in v5.1<\/a> so that programs can now gain a handle for a process ID right at fork()<\/code> (actually clone()<\/code>) time, instead of needing to get the handle from \/proc<\/code> after process creation. With signals and forking now enabled, the next major piece (already in linux-next) will be adding P_PIDFD<\/code> to the waitid()<\/code> system call, and common process management can be done entirely with pidfd.<\/p>\n

Other things<\/strong>
\nAlexander Popov pointed out some more v5.2 features<\/a> that I missed in this blog post. I’m repeating them here, with some minor edits\/clarifications. Thank you Alexander!<\/p>\n