On Mon, Mar 25, 2024 at 10:03:23AM +0100, Vlastimil Babka wrote: > On 3/5/24 11:10 AM, Kees Cook wrote: > > Hi, > > > > Repeating the commit logs for patch 4 here: > > > > Dedicated caches are available For fixed size allocations via > > kmem_cache_alloc(), but for dynamically sized allocations there is only > > the global kmalloc API's set of buckets available. This means it isn't > > possible to separate specific sets of dynamically sized allocations into > > a separate collection of caches. > > > > This leads to a use-after-free exploitation weakness in the Linux > > kernel since many heap memory spraying/grooming attacks depend on using > > userspace-controllable dynamically sized allocations to collide with > > fixed size allocations that end up in same cache. > > > > While CONFIG_RANDOM_KMALLOC_CACHES provides a probabilistic defense > > against these kinds of "type confusion" attacks, including for fixed > > same-size heap objects, we can create a complementary deterministic > > defense for dynamically sized allocations. > > > > In order to isolate user-controllable sized allocations from system > > allocations, introduce kmem_buckets_create(), which behaves like > > kmem_cache_create(). (The next patch will introduce kmem_buckets_alloc(), > > which behaves like kmem_cache_alloc().) > > > > Allows for confining allocations to a dedicated set of sized caches > > (which have the same layout as the kmalloc caches). > > > > This can also be used in the future once codetag allocation annotations > > exist to implement per-caller allocation cache isolation[0] even for > > dynamic allocations. > > > > Link: https://lore.kernel.org/lkml/202402211449.401382D2AF@keescook [0] > > > > After the implemetation are 2 example patches of how this could be used > > for some repeat "offenders" that get used in exploits. There are more to > > be isolated beyond just these. Repeating the commit log for patch 8 here: > > > > The msg subsystem is a common target for exploiting[1][2][3][4][5][6] > > use-after-free type confusion flaws in the kernel for both read and > > write primitives. Avoid having a user-controlled size cache share the > > global kmalloc allocator by using a separate set of kmalloc buckets. > > > > Link: https://blog.hacktivesecurity.com/index.php/2022/06/13/linux-kernel-exploit-development-1day-case-study/ [1] > > Link: https://hardenedvault.net/blog/2022-11-13-msg_msg-recon-mitigation-ved/ [2] > > Link: https://www.willsroot.io/2021/08/corctf-2021-fire-of-salvation-writeup.html [3] > > Link: https://a13xp0p0v.github.io/2021/02/09/CVE-2021-26708.html [4] > > Link: https://google.github.io/security-research/pocs/linux/cve-2021-22555/writeup.html [5] > > Link: https://zplin.me/papers/ELOISE.pdf [6] > > Hi Kees, > > after reading [1] I think the points should be addressed, mainly about the > feasibility of converting users manually. Sure, I can do that. Adding Julien to this thread... Julien can you please respond to LKML patches in email? It's much easier to keep things in a single thread. :) ] This is playing wack-a-mole Kind of, but not really. These patches provide a mechanism for having dedicated dynamically-sized slab caches (to match kmem_cache_create(), which only works for fixed-size allocations). This is needed to expand the codetag work into doing per-call-site allocations, as I detailed here[1]. Also, adding uses manually isn't very difficult, as can be seen in the examples I included. In fact, my examples between v1 and v2 collapsed from 3 to 2, because covering memdup_user() actually covered 2 known allocation paths (attrs and vma names), and given its usage pattern, will cover more in the future without changes. ] something like AUTOSLAB would be better Yes, that's the goal of [1]. This is a prerequisite for that, as mentioned in the cover letter. ] The slabs needs to be pinned Yes, and this is a general problem[2] with all kmalloc allocations, though. This isn't unique to to this patch series. SLAB_VIRTUAL solves it, and is under development. ] Lacks guard pages Yes, and again, this is a general problem with all kmalloc allocations. Solving it, like SLAB_VIRTUAL, would be a complementary hardening improvement to the allocator generally. ] PAX_USERCOPY has been marking these sites since 2012 Either it's whack-a-mole or it's not. :) PAX_USERCOPY shows that it _is_ possible to mark all sites. Regardless, like AUTOSLAB, PAX_USERCOPY isn't upstream, and its current implementation is an unpublished modification to a GPL project. I look forward to someone proposing it for inclusion in Linux, but for now we can work with the patches where an effort _has_ been made to upstream them for the benefit of the entire ecosystem. ] What about CONFIG_KMALLOC_SPLIT_VARSIZE This proposed improvement is hampered by not having dedicated _dynamically_ sized kmem caches, which this series provides. And with codetag-split allocations[1], the goals of CONFIG_KMALLOC_SPLIT_VARSIZE are more fully realized, providing much more complete coverage. ] I have no idea how the community around the Linux kernel works with ] their email-based workflows Step 1: reply to the proposal in email instead of (or perhaps in addition to) making blog posts. :) > On a related technical note I > worry what will become of /proc/slabinfo when we convert non-trivial amounts > of users. It gets longer. :) And potentially makes the codetag /proc file redundant. All that said, there are very few APIs in the kernel where userspace can control both the size and contents of an allocation. > Also would interested to hear Jann Horn et al.'s opinion, and whether the > SLAB_VIRTUAL effort will continue? SLAB_VIRTUAL is needed to address the reclamation UAF gap, and is still being developed. I don't intend to let it fall off the radar. (Which is why I included Jann and Matteo in CC originally.) In the meantime, adding this series as-is kills two long-standing exploitation methodologies, and paves the way to providing very fine-grained caches using codetags (which I imagine would be entirely optional and trivial to control with a boot param). -Kees [1] https://lore.kernel.org/lkml/202402211449.401382D2AF@keescook/ [2] https://googleprojectzero.blogspot.com/2021/10/how-simple-linux-kernel-memory.html -- Kees Cook
