{"id":1121,"date":"2018-04-12T17:04:22","date_gmt":"2018-04-13T00:04:22","guid":{"rendered":"https:\/\/outflux.net\/blog\/?p=1121"},"modified":"2019-02-26T11:58:05","modified_gmt":"2019-02-26T19:58:05","slug":"security-things-in-linux-v4-16","status":"publish","type":"post","link":"https:\/\/outflux.net\/blog\/archives\/2018\/04\/12\/security-things-in-linux-v4-16\/","title":{"rendered":"security things in Linux v4.16"},"content":{"rendered":"

Previously: v4.15<\/a>.
\n\ufffc
\nLinux kernel v4.16 was released<\/a> last week. I really should write these posts in advance, otherwise I get distracted by the merge window. Regardless, here are some of the security things I think are interesting:<\/p>\n

KPTI on arm64<\/strong><\/p>\n

Will Deacon, Catalin Marinas, and several other folks brought Kernel Page Table Isolation<\/a> (via CONFIG_UNMAP_KERNEL_AT_EL0<\/code><\/a>) to arm64. While most ARMv8+ CPUs were not vulnerable to the primary Meltdown flaw, the Cortex-A75<\/a> does need KPTI to be safe from memory content leaks. It’s worth noting, though, that KPTI does protect other ARMv8+ CPU models from having privileged register contents exposed<\/a>. So, whatever your threat model, it’s very nice to have this clean isolation between kernel and userspace page tables for all ARMv8+ CPUs.<\/p>\n

hardened usercopy whitelisting<\/strong><\/p>\n

While whole-object bounds checking was implemented in CONFIG_HARDENED_USERCOPY already<\/a>, David Windsor and I finished another part of the porting work of grsecurity’s PAX_USERCOPY protection: usercopy whitelisting<\/a>. This further tightens the scope of slab allocations that can be copied to\/from userspace. Now, instead of allowing all objects in slab memory to be copied, only the whitelisted areas (where a subsystem has specifically marked the memory region allowed) can be copied. For example, only the auxv array out of the larger mm_struct<\/a>.<\/p>\n

As mentioned in the first commit from the series<\/a>, this reduces the scope of slab memory that could be copied out of the kernel in the face of a bug to under 15%. As can be seen, one area of work remaining are the kmalloc<\/code> regions. Those are regularly used for copying things in and out of userspace, but they’re also used for small simple allocations that aren’t meant to be exposed to userspace. Working to separate these kmalloc<\/code> users needs some careful auditing.<\/p>\n

\r\n
Total Slab Memory:           48074720\r\nUsercopyable Memory:          6367532  13.2%\r\n         task_struct                    0.2%         4480\/1630720\r\n         RAW                            0.3%            300\/96000\r\n         RAWv6                          2.1%           1408\/64768\r\n         ext4_inode_cache               3.0%       269760\/8740224\r\n         dentry                        11.1%       585984\/5273856\r\n         mm_struct                     29.1%         54912\/188448\r\n         kmalloc-8                    100.0%          24576\/24576\r\n         kmalloc-16                   100.0%          28672\/28672\r\n         kmalloc-32                   100.0%          81920\/81920\r\n         kmalloc-192                  100.0%          96768\/96768\r\n         kmalloc-128                  100.0%        143360\/143360\r\n         names_cache                  100.0%        163840\/163840\r\n         kmalloc-64                   100.0%        167936\/167936\r\n         kmalloc-256                  100.0%        339968\/339968\r\n         kmalloc-512                  100.0%        350720\/350720\r\n         kmalloc-96                   100.0%        455616\/455616\r\n         kmalloc-8192                 100.0%        655360\/655360\r\n         kmalloc-1024                 100.0%        812032\/812032\r\n         kmalloc-4096                 100.0%        819200\/819200\r\n         kmalloc-2048                 100.0%      1310720\/1310720\r\n<\/blockquote>\r\n<\/pre>\n
This series took quite a while to land (you can see David’s original patch date as back in June of last year). Partly this was due to having to spend a lot of time researching the code paths so that each whitelist could be explained for commit logs, partly due to making various adjustments from maintainer feedback, and partly due to the short merge window in v4.15 (when it was originally proposed for merging) combined with some last-minute glitches that made Linus nervous. After baking in linux-next<\/code> for almost two full development cycles, it finally landed. (Though be sure to disable<\/em> CONFIG_HARDENED_USERCOPY_FALLBACK<\/code> to gain enforcement of the whitelists — by default it only warns and falls back to the full-object checking.)<\/p>\n
automatic stack-protector<\/strong><\/p>\n
While the stack-protector features of the kernel have existed for quite some time, it has never been enabled by default. This was mainly due to needing to evaluate compiler support for the feature, and Kconfig<\/code> didn’t have a way to check the compiler features before offering CONFIG_*<\/code> options. As a defense technology, the stack protector is pretty mature. Having it on by default would have greatly reduced the impact of things like the BlueBorne<\/a> attack (CVE-2017-1000251), as fewer systems would have lacked the defense.<\/p>\n
After spending quite a bit of time fighting <\/a>with ancient compiler versions (*cough*GCC 4.4.4*cough*), I landed CONFIG_CC_STACKPROTECTOR_AUTO<\/code><\/a>, which is default on, and tries to use the stack protector if it is available. The implementation of the solution, however, did not please Linus, though he allowed it to be merged. In the future, Kconfig will gain the knowledge to make better decisions<\/a> which lets the kernel expose the availability of (the now default) stack protector directly in Kconfig<\/code>, rather than depending on rather ugly Makefile<\/code> hacks.<\/p>\n
execute-only memory for PowerPC<\/strong><\/p>\n
Similar to the Protection Keys (pkeys<\/a>) hardware support that landed in v4.6 for x86<\/a>, Ram Pai landed pkeys support for Power7\/8\/9<\/a>. This should expand the scope of what’s possible in the dynamic loader to avoid having arbitrary read flaws allow an exploit to read out all of executable memory in order to find ROP gadgets.<\/p>\n
That’s it for now; let me know if you think I should add anything! The v4.17<\/a> merge window is open. :)<\/p>\n
Edit<\/em>: added details on ARM register leaks, thanks to Daniel Micay.<\/p>\n
Edit<\/em>: added section on protection keys for POWER, thanks to Florian Weimer.<\/p>\n
© 2018 – 2019, 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: v4.15. \ufffc Linux kernel v4.16 was released last week. I really should write these posts in advance, otherwise I get distracted by the merge window. Regardless, here are some of the security things I think are interesting: KPTI on arm64 Will Deacon, Catalin Marinas, and several other folks brought Kernel Page Table Isolation (via […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,18,21,6,14,19],"tags":[],"_links":{"self":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/1121"}],"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=1121"}],"version-history":[{"count":18,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/1121\/revisions"}],"predecessor-version":[{"id":1237,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/1121\/revisions\/1237"}],"wp:attachment":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/media?parent=1121"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/categories?post=1121"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/tags?post=1121"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}