{"id":1349,"date":"2019-11-14T17:36:21","date_gmt":"2019-11-15T01:36:21","guid":{"rendered":"https:\/\/outflux.net\/blog\/?p=1349"},"modified":"2020-08-03T14:51:39","modified_gmt":"2020-08-03T21:51:39","slug":"security-things-in-linux-v5-3","status":"publish","type":"post","link":"https:\/\/outflux.net\/blog\/archives\/2019\/11\/14\/security-things-in-linux-v5-3\/","title":{"rendered":"security things in Linux v5.3"},"content":{"rendered":"

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

Linux kernel v5.3 was released<\/a>! I let this blog post get away from me, but it’s up now! :) Here are some security-related things I found interesting:<\/p>\n

heap variable initialization<\/strong>
\nIn the continuing work to remove “uninitialized” variables<\/a> from the kernel, Alexander Potapenko added new “init_on_alloc<\/code>” and “init_on_free<\/code>” boot parameters<\/a> (with associated Kconfig defaults) to perform zeroing of heap memory either at allocation time (i.e. all kmalloc()<\/code>s effectively become kzalloc()<\/code>s), at free time (i.e. all kfree()<\/code>s effectively become kzfree()<\/code>s), or both. The performance impact of the former under most workloads appears to be under 1%, if it’s measurable at all. The “init_on_free” option, however, is more costly but adds the benefit of reducing the lifetime of heap contents after they have been freed (which might be useful for some use-after-free attacks or side-channel attacks). Everyone should enable CONFIG_INIT_ON_ALLOC_DEFAULT_ON=1<\/code> (or boot with “init_on_alloc=1<\/code>“), and the more paranoid system builders should add CONFIG_INIT_ON_FREE_DEFAULT_ON=1<\/code> (or “init_on_free=1<\/code>” at boot). As workloads are found that cause performance concerns, tweaks to the initialization coverage can be added.<\/p>\n

pidfd_open()<\/code> added<\/strong>
\nChristian Brauner has continued his pidfd<\/code> work<\/a> by creating the next needed syscall: pidfd_open()<\/code><\/a>, which takes a pid<\/code> and returns a pidfd<\/code>. This is useful for cases where process creation isn’t yet using CLONE_PIDFD<\/code>, and where \/proc<\/code> may not be mounted.<\/p>\n

-Wimplicit-fallthrough<\/code> enabled globally<\/strong>
\nGustavo A.R. Silva landed the last handful of implicit fallthrough<\/a> fixes left in the kernel, which allows for -Wimplicit-fallthrough<\/code> to be globally enabled<\/a> for all kernel builds. This will keep any new instances of this bad code pattern from entering the kernel again. With several hundred implicit fallthroughs identified and fixed, something like 1 in 10 were missing breaks, which is way higher than I was expecting, making this work even more well justified.<\/p>\n

x86 CR4 & CR0 pinning<\/strong>
\nIn recent exploits<\/a>, one of the steps for making the attacker’s life easier is to disable CPU protections like Supervisor Mode Access (and Execute) Prevention (SMAP and SMEP) by finding a way to write to CPU control registers to disable these features. For example, CR4 controls SMAP and SMEP, where disabling those would let an attacker access and execute userspace memory from kernel code again, opening up the attack to much greater flexibility. CR0 controls Write Protect (WP), which when disabled would allow an attacker to write to read-only memory like the kernel code itself. Attacks have been using the kernel’s CR4 and CR0 writing functions to make these changes (since it’s easier to gain that level of execute control), but now the kernel will attempt to “pin” sensitive bits in CR4<\/a> and CR0<\/a> to avoid them getting disabled. This forces attacks to do more work to enact such register changes going forward. (I’d like to see KVM enforce this too, which would actually protect guest kernels from all attempts to change protected register bits.)<\/p>\n

additional kfree()<\/code> sanity checking<\/strong>
\nIn order to avoid corrupted pointers doing crazy things when they’re freed (as seen in recent exploits<\/a>), I added additional sanity checks to verify kmem cache membership<\/a> and to make sure that objects actually belong to the kernel slab heap<\/a>. As a reminder, everyone should be building with CONFIG_SLAB_FREELIST_HARDENED=1<\/code>.<\/p>\n

KASLR enabled by default on arm64<\/strong>
\nJust as Kernel Address Space Layout Randomization (KASLR) was enabled by default on x86<\/a>, now KASLR has been enabled by default on arm64<\/a> too. It’s worth noting, though, that in order to benefit from this setting, the bootloader used for such arm64 systems needs to either support the UEFI RNG function or provide entropy via the “\/chosen\/kaslr-seed<\/code>” Device Tree property.<\/p>\n

hardware security embargo documentation<\/strong>
\nAs there continues to be a long tail of hardware flaws that need to be reported to the Linux kernel community under embargo, a well-defined process has been documented<\/a>. This will let vendors unfamiliar with how to handle things follow the established best practices for interacting with the Linux kernel community in a way that lets mitigations get developed before embargoes are lifted. The latest (and HTML rendered) version of this process should always be available here<\/a>.<\/p>\n

Those are the things I had on my radar. Please let me know if there are other things I should add! Linux v5.4<\/a> is almost here…<\/p>\n

© 2019 – 2020, 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.2. Linux kernel v5.3 was released! I let this blog post get away from me, but it’s up now! :) Here are some security-related things I found interesting: heap variable initialization In the continuing work to remove “uninitialized” variables from the kernel, Alexander Potapenko added new “init_on_alloc” and “init_on_free” boot parameters (with associated Kconfig […]<\/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\/1349"}],"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=1349"}],"version-history":[{"count":19,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/1349\/revisions"}],"predecessor-version":[{"id":1401,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/1349\/revisions\/1401"}],"wp:attachment":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/media?parent=1349"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/categories?post=1349"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/tags?post=1349"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}