{"id":1171,"date":"2018-06-14T16:23:56","date_gmt":"2018-06-14T23:23:56","guid":{"rendered":"https:\/\/outflux.net\/blog\/?p=1171"},"modified":"2018-10-18T13:56:10","modified_gmt":"2018-10-18T20:56:10","slug":"security-things-in-linux-v4-17","status":"publish","type":"post","link":"https:\/\/outflux.net\/blog\/archives\/2018\/06\/14\/security-things-in-linux-v4-17\/","title":{"rendered":"security things in Linux v4.17"},"content":{"rendered":"

Previously: v4.16<\/a>.<\/p>\n

Linux kernel v4.17 was released last week<\/a>, and here are some of the security things I think are interesting:<\/p>\n

Jailhouse hypervisor<\/strong><\/p>\n

Jan Kiszka landed<\/a> Jailhouse hypervisor<\/a> support, which uses static partitioning (i.e. no resource over-committing), where the root “cell” spawns new jails by shrinking its own CPU\/memory\/etc resources and hands them over to the new jail. There’s a nice write-up of the hypervisor on LWN from 2014<\/a>.<\/p>\n

Sparc ADI<\/strong><\/p>\n

Khalid Aziz landed<\/a> the userspace support for Sparc Application Data Integrity<\/a> (ADI or SSM: Silicon Secured Memory), which is the hardware memory coloring (tagging) feature in Sparc M7. I’d love to see this extended into the kernel itself, as it would kill linear overflows between allocations, since the base pointer being used is tagged to belong to only a certain allocation (sized to a multiple of cache lines). Any attempt to increment beyond, into memory with a different tag, raises an exception. Enrico Perla has some great write-ups on using ADI in allocators<\/a> and a comparison of ADI to Intel’s MPX<\/a>.<\/p>\n

new kernel stacks cleared on fork<\/strong><\/p>\n

It was possible that old memory contents would live in a new process’s kernel stack. While normally not visible, “uninitialized” memory read flaws or read overflows could expose these contents (especially stuff “deeper” in the stack that may never get overwritten for the life of the process). To avoid this, I made sure that new stacks were always zeroed<\/a>. Oddly, this “priming” of the cache appeared to actually improve performance, though it was mostly in the noise.<\/p>\n

MAP_FIXED_NOREPLACE<\/strong><\/p>\n

As part of further defense in depth against attacks like Stack Clash<\/a>, Michal Hocko created MAP_FIXED_NOREPLACE<\/code><\/a>. The regular MAP_FIXED<\/code> has a subtle behavior not normally noticed (but used by some, so it couldn’t just be fixed): it will replace<\/em> any overlapping portion of a pre-existing mapping. This means the kernel would silently overlap the stack into mmap or text regions, since MAP_FIXED<\/code> was being used to build a new process’s memory layout. Instead, MAP_FIXED_NOREPLACE<\/code> has all the features of MAP_FIXED<\/code> without<\/em> the replacement behavior: it will fail if a pre-existing mapping overlaps with the newly requested one. The ELF loader has been switched to use MAP_FIXED_NOREPLACE<\/code>, and it’s available to userspace too, for similar use-cases.<\/p>\n

pin stack limit during exec<\/strong><\/p>\n

I used a big hammer and pinned the RLIMIT_STACK<\/code> values during exec<\/a>. There were multiple methods to change the limit (through at least setrlimit()<\/code> and prlimit()<\/code>), and there were multiple places the limit got used to make decisions, so it seemed best to just pin the values for the life of the exec so no games could get played with them. Too much assumed the value wasn’t changing, so better to make that assumption actually true. Hopefully this is the last of the fixes<\/a> for these bad interactions between stack limits and memory layouts during exec (which have all been defensive measures against flaws like Stack Clash<\/a>). <\/p>\n

Variable Length Array removals start<\/strong><\/p>\n

Following some discussion over Alexander Popov’s ongoing port of the stackleak GCC plugin<\/a>, Linus declared that Variable Length Arrays (VLAs) should be eliminated from the kernel entirely<\/a>. This is great because it kills several stack exhaustion attacks, including weird stuff like stepping over guard pages with giant stack allocations. However, with several hundred uses in the kernel, this wasn’t going to be an easy job. Thankfully, a whole bunch of people stepped up to help out<\/a>: Gustavo A. R. Silva, Himanshu Jha, Joern Engel, Kyle Spiers, Laura Abbott, Lorenzo Bianconi, Nikolay Borisov, Salvatore Mesoraca, Stephen Kitt, Takashi Iwai, Tobin C. Harding, and Tycho Andersen. With Linus Torvalds and Martin Uecker, I also helped rewrite the max()<\/code> macro<\/a> to eliminate false positives<\/a> seen by the -Wvla<\/code> compiler option. Overall, about 1\/3rd of the VLA instances were solved for v4.17, with many more coming for v4.18. I’m hoping we’ll have entirely eliminated VLAs by the time v4.19 ships.<\/p>\n

Edit: I missed this next feature when I first published this post:<\/em><\/p>\n

syscall register clearing, x86<\/strong><\/p>\n

One of the ways attackers can influence potential speculative execution flaws in the kernel is to leak information into the kernel via “unused” register contents. Most syscalls take only a few arguments, so all the other calling-convention-defined registers<\/a> can be cleared instead of just left with whatever contents they had in userspace. As it turns out, clearing registers is very fast. Dominik Brodowski expanded a proof-of-concept from Linus Torvalds into a full register-clearing syscall wrapper on x86<\/a>.<\/p>\n

That’s it for now! Please let me know if you think I missed anything. Stay tuned for v4.18<\/a>; the merge window is open. :)<\/p>\n

© 2018, 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.16. Linux kernel v4.17 was released last week, and here are some of the security things I think are interesting: Jailhouse hypervisor Jan Kiszka landed Jailhouse hypervisor support, which uses static partitioning (i.e. no resource over-committing), where the root “cell” spawns new jails by shrinking its own CPU\/memory\/etc resources and hands them over to […]<\/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\/1171"}],"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=1171"}],"version-history":[{"count":12,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/1171\/revisions"}],"predecessor-version":[{"id":1198,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/1171\/revisions\/1198"}],"wp:attachment":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/media?parent=1171"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/categories?post=1171"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/tags?post=1171"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}