From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B6F6DC54E64 for ; Mon, 25 Mar 2024 18:24:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 428CF6B0083; Mon, 25 Mar 2024 14:24:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3B1036B0085; Mon, 25 Mar 2024 14:24:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 22B5F6B0087; Mon, 25 Mar 2024 14:24:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 0E1A66B0083 for ; Mon, 25 Mar 2024 14:24:22 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id C18BD1401A4 for ; Mon, 25 Mar 2024 18:24:21 +0000 (UTC) X-FDA: 81936386322.21.290ACA5 Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) by imf01.hostedemail.com (Postfix) with ESMTP id E07A840010 for ; Mon, 25 Mar 2024 18:24:19 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=fHhhkYLa; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf01.hostedemail.com: domain of keescook@chromium.org designates 209.85.215.177 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711391060; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=xwJ6aw89XG6ag1cAMAye4X3OlKaivOSj4AMu57dyHZA=; b=DE5dEZ93zpj8zd39IFqfHd+wY1jnPSWDL2b0dZlkbx6MSm1JFCpZFX1wD4R36rmlefIxho fIqi6hF1qAHZQ1I1qVOpj+GJX1h64aL+TIpHvrn0s3km4L7DcVmURAzLXSEMGCbI/zTXI/ 2CiclQfVrkJ+MyckyJx6MTaR89BFVro= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=fHhhkYLa; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf01.hostedemail.com: domain of keescook@chromium.org designates 209.85.215.177 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711391060; a=rsa-sha256; cv=none; b=GxiRtUgumZM4KAY69Wm7Exy3E9OVZXFVgNeSlzfolYE0O/FoBShluUC5ldaO3geQqqn+JA 2cZpWPGTJFoUcwisW9dhLRHK2HcLt9E+lhqLEhN8BnM3NmL8fOnKNKKfRIoGZEZyCRLqb5 mr8h8+y1OVK1JpK5NaxdApXmMLKe9JU= Received: by mail-pg1-f177.google.com with SMTP id 41be03b00d2f7-5cedfc32250so2894648a12.0 for ; Mon, 25 Mar 2024 11:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1711391058; x=1711995858; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=xwJ6aw89XG6ag1cAMAye4X3OlKaivOSj4AMu57dyHZA=; b=fHhhkYLaoOGoG9SQSvJkhCa6Xp6RD/JO+Meob/EWUKErW7WXE2m/e4x9O/kt3OZKAS 4gUbshkjwAvcXlYouRCwC3HzatBvMypviLsVM72GeyZqoUmVCZB0beKY4JY64pqwAsmr o4VMc5rAPXSxhcJ3a9VdwMcL/Hg8ZisPaAtEo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711391058; x=1711995858; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=xwJ6aw89XG6ag1cAMAye4X3OlKaivOSj4AMu57dyHZA=; b=fCNZdZdDXUcK8z+synWXFgshqj7MupylsLin+qZduKCexX0VYhA/pY1FhSRvFU71e9 xBX1EQrwVRAWDyp+KwwitEIRxHAb3Q8/dzZM+0n+5q6UOm6uVa8qLym26OdHmxxMF47X ApoICgbcGVHFsdiF4hCGvwN6F9LgYEAN9/wXVdeaZLJR7LbKSgov7y49rZMO6xfqZMz/ 4sKNouEQAX5KHF8EIxKSfguy3uZwyG3Z/Nvl0Wa9j052kM/vx6jYahrHOJ6up2D+LVm8 y5yeyo5F/b6y5lBhQEh0mFzVja9xTk3Cl3/2CtK+Sf9SiVUmZWYGGrNsx13LISiQkSUH TztQ== X-Forwarded-Encrypted: i=1; AJvYcCU1cmjImqWDYZu8LqgBgk0GnG/KxFTV1xeNLma2UUiFo9Gy+5ShJm2avhrILbQxZxKksdvNTmVhhZzVcR0BcHeqLvU= X-Gm-Message-State: AOJu0YzROtCyWQjRFvLouwEM8nnRTOLVAf9eAQH0pX/f8VBQiXh7HwJb WLHQtHIfzQK/TFEhUP/EwPF+LW1Hh+P5lymt0IwpXTF778TUyJ1it4pCPROAIA== X-Google-Smtp-Source: AGHT+IHNRBPKz7IkJD3yJgMjJGAVIzlGXkznLyu7qd+9aDITzPOvbPJuNphM2uFoaTabaqgGZ3ou/w== X-Received: by 2002:a17:90a:f285:b0:2a0:390e:f072 with SMTP id fs5-20020a17090af28500b002a0390ef072mr5691880pjb.40.1711391058608; Mon, 25 Mar 2024 11:24:18 -0700 (PDT) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id qa14-20020a17090b4fce00b002a04f430937sm4349793pjb.43.2024.03.25.11.24.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Mar 2024 11:24:18 -0700 (PDT) Date: Mon, 25 Mar 2024 11:24:17 -0700 From: Kees Cook To: Vlastimil Babka , Julien Voisin Cc: Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, "GONG, Ruiqi" , Xiu Jianfeng , Suren Baghdasaryan , Kent Overstreet , Jann Horn , Matteo Rizzo , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-hardening@vger.kernel.org, jvoisin Subject: Re: [PATCH v2 0/9] slab: Introduce dedicated bucket allocator Message-ID: <202403250958.DAFA70CC@keescook> References: <20240305100933.it.923-kees@kernel.org> <5e1571de-2c5a-4be4-93f4-01582094ee96@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5e1571de-2c5a-4be4-93f4-01582094ee96@suse.cz> X-Rspam-User: X-Stat-Signature: x767xpdwhke1jbozw9ya1cxom4fb3xek X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: E07A840010 X-HE-Tag: 1711391059-539326 X-HE-Meta: U2FsdGVkX19V1DfxPCKMkWTArBZcjarwDURAFfHcP7h/+T7RSB3QhbgpH36MfoRWL9rE5v+p621bN1+LNz644coGXZKrCDj318a5ekx/47B3zlFMWx9J0zWfGpzUOl5t7YEofkIXLQGNUJCdQhOeGe2RMwgQSolEAIuOzpvNprQFG9kCmKZySS2cOvsInJQ2jZiJl2MZLaXVGPOB19iw63hbWomG1N2p61D9i9C8uE5Gxx5EOBdcxUY0vr+cTAalLRbUFEaMIJ/syZqhM3mTn1G2azMsrQzsLNo7PlH2kEczkoWuChm39/zlBtw8c/kIN99vIspaP1eHwKK/JScLvqeXV2yl/RPIfWAQIaPu2jsJEB4Igr+vGjnigvjprLVNp1d3ktPWf5QAH8vXjL6CzLH+RbsthsB+VG7pMb4FJyYnGwg42tik7g5WV5CjaikNJfpffpJTzshduYwKDzg9LLt1WwN9i8LTfNGw2yyF5sVAQMFrLDtrCujuQ5Cn59HXGeKNmg4T7rFYGTGyCgMn2KI38bhii2VUt9OhvjmA20ntevXAZLbMtyMFgWKxZmmviJ9CsBQYw2Mry2M/HWH6V2WZzxpIx32wxXnCiYBlxUoxUQ8mgn9YiCEhs4Wbgg3hbfyeXSjNICy4AvhKIIGjq1Xiw1wdlr0aOxokhFsxkKXTxYyucIRmec+2mSmF/aXVU3zUG+apn/pB7EgE8gLfH3IdlAv6aOk6phu0l2GIjFsu4l2On/VdBmk4ijSRRqK+84wjXqQLEOwikCcV8S42vUccRg4CGhAIQueaGbA99GRRplPijneAjknixI3c5z8l6pxe+rUc8GO52IOPehO5faunBnUOgmtGT/ooLsJHn9dH1EIGoSwhUf/m+f7THSt+v0rByPJZJNwzOsyL+79TSC4RTRyQTyRGz+ZDQXpBqgWsvVo3VzRuB+CFJuScYVF11RnCLoaheSR07Eg037z TKl19L12 tBnq7hN5h9vuCyZW5pSY5RhbYvUl97MDwdk0H2NxheVjsVhgAyqlCc94/vsobQ92Q9TeGY7qFjtknMvS0ij3NjHAPs8sHVSRP6x8QiGhEqa8FAfPNhuLfKJN3NtSrl0tsOTg4Tp8vCcScZVcEzMWf6xoEXm69g/muwCj2IlFIF7yE0zDcaoQQuDmruGnzk0CxYkWRFzx0ep9K5Z6xsJKGbs00Ov8oko0DlhjPSevw139c1QIESP5n6GkWEZTazQfviLB9W8S14I5l+cmH7KQdIUqz53LFyghRFCLRq9cmV+ZMbRBivTzm4OrErOO8mwu0N93MakZhDmXCNrETnpMr5fKWU5VQ61xTT33N8vdxnDwNjwkS8luQTzEk9GMl2ynJq/XMtZgjua8rvrelJiEX2FUEBPHNJI9qb5KCgjSIxCvHRD1wNoaouGTbAqJNtf/S6xfiYLiYXKEEvoD179dADng/W5ygGg+EwTrgw40P4CakEl2iVSj2/7X9caU1ekPXdCJtm1l/H6I4jF9IBwScjifgRPinhzegZlhHnLmyVEyAhSWcEJv+UPkfJW76qNAH/sCq+ACdbEh9s6meCFvy+gqi+4xyztjCbhjDJoYda5udnnIoR/ESRokzmbSyNz54IUnIaLC3pb+lKEsBPUQPlU0mb8NKK6WUpDU5D/D6QkBzAOmZGWf8Ggczjdvz9k8nGDTmCTG2luaHMxRQMCxbkSfNNcpaOawZgayhuQ8cckNWocujsL3WFZ6aPizQnHznGamhtRgKj8KaqnSGNYjxYcAf+h9ExdD83oanrWHBkq1cWCthlhGhRdnXA+Z4nfgsBAOkz4PiGgx/3YtknCXUbrIjypg+JCQDTqNQ4f0d/YKhfh9ocF/j4eCPymzfZlGEjOV69nEMt8Nu/0wGuxgEbvWb0dpeCf4FRTaQXke824gkacdQ/mjscjwke4hhJExshdidaZkEh/r+BIO71X1+aIPBJ2+r nEBfd7ru CrJoH2y2Xcp8ie/fpF8qgnINEl5lJoKva/7jBgn1l6WUIn80IFld1fV8CVkzJIulpJnLSJeKLXPcHiRHzcM1O3RaXb1/xGnDzjAxGxuu8oWZHu2ngLa5wA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000214, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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