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 025CCC48BEB for ; Thu, 22 Feb 2024 00:58:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4CCD46B0088; Wed, 21 Feb 2024 19:58:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 456436B0089; Wed, 21 Feb 2024 19:58:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2CFC46B008C; Wed, 21 Feb 2024 19:58:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 195BE6B0088 for ; Wed, 21 Feb 2024 19:58:03 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id ACEA6C0BB0 for ; Thu, 22 Feb 2024 00:58:02 +0000 (UTC) X-FDA: 81817628004.07.7F4469E Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by imf25.hostedemail.com (Postfix) with ESMTP id E49A2A0002 for ; Thu, 22 Feb 2024 00:58:00 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=krLpp21E; spf=pass (imf25.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.173 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708563481; 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=ulpOkHFvivSSE+e2M3yzbCAjenVPYV9xC3Luo/BV0yQ=; b=vPO9DL1/FvWIErXutw+DtcsUeoKSsBUqmCc0xlGH2EgorTyn3nbcMBDAoad5zCSq9D8QJg TdZk9fz8mcBwZ0f27WplS8MLR0Ps0LuQC3dJzajmYSMaauPJxPajngTN7G8ZviYL8SkwTr LJMjP1t4pF7WhIvzcUhZQYcGtVi6tWU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708563481; a=rsa-sha256; cv=none; b=vMeiXS+BJKCFfQWsjV4LE33/m1qCgd24afVrb44UNBGNjh0WBYIoeeKTLq+2De6hERVhQy nf7d/F7rUcs+nC0YYtaqeq8+HSgDYczeqoU0pYyP9spr6dUSfuWsj/hMWBQANDKOm1+bkX vrR5Vwd4Oc/sLhdKjmZaLhpvvc4VIfc= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=krLpp21E; spf=pass (imf25.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.173 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-1dc0d11d1b7so28418995ad.2 for ; Wed, 21 Feb 2024 16:58:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1708563480; x=1709168280; 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=ulpOkHFvivSSE+e2M3yzbCAjenVPYV9xC3Luo/BV0yQ=; b=krLpp21ESC/sxQypGU+BQQY6EWJ5s7E4tSUqa8qmMwMKEbVHDK+W8Co1TTPz4hep3B MqnpYALVfBzd3o1lXJYvwDPsoYZE2wv2nGG9EVNbXzikO3TJZmCdMyhDYQhB9hQ3h2lx QYksfxwTcnKu/TgXKwWEvNK5uNQSddXaUCi2I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708563480; x=1709168280; 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=ulpOkHFvivSSE+e2M3yzbCAjenVPYV9xC3Luo/BV0yQ=; b=HIXgojyyk52bJfJH5QH8IEwrBR6G9Ma/pfwv4HEXkSJXBeG+OqFyy8vi4aX6EYBkjP zIU0k2kwU+rrcT+XvQeRL+E2iIKI+0MefaAcZ2dAHgjxIMwP7l1jk2+fe0aANukZLvSB d16YhLBBmQ/RtmNgY2MYpSIS1bSL4Y5UyN2PnxeklcTgG1lx/WzgII0Ugih6lX83CGU8 zxLiVi2DuME4MgUDeMwxI/4ZLixEpr4hjY63UZPwflvRIpqaf/asUhGnK+kegRLbWne8 fiGefP0ZqgTeOsVssbPttH/H/16WN5FkfzPS8YJAgwXSj9MN1ZiiERg6gDNvjvVY1JCL s/3Q== X-Forwarded-Encrypted: i=1; AJvYcCWeylUU2ZT+wWkCqNnEvtvft9XftSEDjOe0yiFngEz1u0hbfAdsfJ8n+kI5SpXLJpm3dUJzozXqPxF05ws+HfyBkYU= X-Gm-Message-State: AOJu0Yx9OVgt9uU+17juSTuJZFFgpRkhbCEB6DE6hbzOsaOitx6rszk7 BJbGm40dCKqn5skbw5H+JaK888PidHTwmSqbqTcltCoKhqb8omoa9W7bu9IzwA== X-Google-Smtp-Source: AGHT+IGm7h5ZV0EzcuKSBZ3gmw/U4fZSzqtkLAWR1rO4mA1qj/36cOnDA8NuYcyFHRYVcqh6I1HhPg== X-Received: by 2002:a17:902:6504:b0:1dc:4aa1:df32 with SMTP id b4-20020a170902650400b001dc4aa1df32mr476220plk.14.1708563479629; Wed, 21 Feb 2024 16:57:59 -0800 (PST) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id l9-20020a170902eb0900b001db63cfe07dsm8723498plb.283.2024.02.21.16.57.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Feb 2024 16:57:59 -0800 (PST) Date: Wed, 21 Feb 2024 16:57:58 -0800 From: Kees Cook To: Kent Overstreet Cc: Suren Baghdasaryan , akpm@linux-foundation.org, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, roman.gushchin@linux.dev, mgorman@suse.de, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, penguin-kernel@i-love.sakura.ne.jp, corbet@lwn.net, void@manifault.com, peterz@infradead.org, juri.lelli@redhat.com, catalin.marinas@arm.com, will@kernel.org, arnd@arndb.de, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, x86@kernel.org, peterx@redhat.com, david@redhat.com, axboe@kernel.dk, mcgrof@kernel.org, masahiroy@kernel.org, nathan@kernel.org, dennis@kernel.org, tj@kernel.org, muchun.song@linux.dev, rppt@kernel.org, paulmck@kernel.org, pasha.tatashin@soleen.com, yosryahmed@google.com, yuzhao@google.com, dhowells@redhat.com, hughd@google.com, andreyknvl@gmail.com, ndesaulniers@google.com, vvvvvv@google.com, gregkh@linuxfoundation.org, ebiggers@google.com, ytcoode@gmail.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, bristot@redhat.com, vschneid@redhat.com, cl@linux.com, penberg@kernel.org, iamjoonsoo.kim@lge.com, 42.hyeyoo@gmail.com, glider@google.com, elver@google.com, dvyukov@google.com, shakeelb@google.com, songmuchun@bytedance.com, jbaron@akamai.com, rientjes@google.com, minchan@google.com, kaleshsingh@google.com, kernel-team@android.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arch@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, kasan-dev@googlegroups.com, cgroups@vger.kernel.org Subject: Re: [PATCH v4 14/36] lib: add allocation tagging support for memory allocation profiling Message-ID: <202402211656.C3644FB@keescook> References: <20240221194052.927623-1-surenb@google.com> <20240221194052.927623-15-surenb@google.com> <202402211449.401382D2AF@keescook> <4vwiwgsemga7vmahgwsikbsawjq5xfskdsssmjsfe5hn7k2alk@b6ig5v2pxe5i> <202402211608.41AD94094@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: E49A2A0002 X-Rspam-User: X-Stat-Signature: iqt7rgsiq1uksn6whtdydm9dir1i7w5f X-Rspamd-Server: rspam03 X-HE-Tag: 1708563480-624694 X-HE-Meta: U2FsdGVkX1+7Ubq+WZnr84DaoxDWB6gQgaHS9Wnu6Jg5WNF3cKDkcEvNqNWvadue674aWrwlQBKloS4OYpMVD82I59NpU6YH5Yq9032yqL1egEaF/w8qUTreMiZR1xYB3KzJdIbcQyU+TRfuoSECSmo3O+q8478idsKc6VQeuxMmLLetbunShvBOckZnCGcL12EE4AenmknduzPFCfkxZd++PfZFCWLEn29OE5604cBA7GrC10CYEaD1NO1Grg3LHOaDduYGyiJccAu2qny9MKK8jvYyow+4FnkRVMQ0lndUIFNcW2qaWLC2GFcQImRmzG5BG7ARTC3HjgDAp2igZKuX0D3adMf6lcDzwF2Hxp/v+bIajhIHqVky9B5S/hyy7gBNiq4Wm7n1FEJ0jNdOLQ00AduBmHZPMB/w2QFiSmftoZO35C6T6tBIch0PPBosG45eiZZJOoFhUYFHabski+ull5kU4ZihWkmRxdOSYIit0Vw7cVimP7+XeTNO+AEc+IJsib9jPuU+kohMCb5kSRt7l1IvZ1z6fnBQvMAm5y95pR6FgE284e1M3Gza5djDz2NwKsm+03DTWhFlcxZGr20Rujm3RmwKtsstWMOfCQuoK0H9kheNTwYVW/L7+C8jmODj8QHvL/ScbPeZkO1NqOqV4AQHaAtIme+wsR2OjCUWAg8CVPIxwdA829yQfwInfBqYVNqvqKHo1H23PqReVbDGhEUd6MOtbOArDN+02Y3mBWv0HDHBfXAzgAZOcrurKjaOoejdSQ2es6SjoFa4i01TRA0sJWFgAfrnJTbMLXj3YWETuUo03E3LI4PENscwMv5u3105cBoR7mDrP+rv07fq4zwfWkzTF5uVg53SpY5Bc34GAOisqBjfufbqwsVwclnLvoVbPF4j7OYgr79aqB0Uu1jD901NYZIOm5DNEXTORjuQrf5ynQ3IfzWwaB89j6cM9tOXNhsrml67lHD ZE9YJGWV UHl2yJrno6u2dkFD+Oju06tgyCSScM9TsVzv7X+e6/0A39Bt/C5vTOWEuHClUaSQ6Q3Oc7IursFfbAUmbg6dhtVPZFL7T15DNnqDfHs+DtzEgiziESEt4cuSe9R9nHP3PBdiPEOIHiCGPnSjZUzm7D8wtEg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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 Wed, Feb 21, 2024 at 07:34:44PM -0500, Kent Overstreet wrote: > On Wed, Feb 21, 2024 at 04:25:02PM -0800, Kees Cook wrote: > > On Wed, Feb 21, 2024 at 06:29:17PM -0500, Kent Overstreet wrote: > > > On Wed, Feb 21, 2024 at 03:05:32PM -0800, Kees Cook wrote: > > > > On Wed, Feb 21, 2024 at 11:40:27AM -0800, Suren Baghdasaryan wrote: > > > > > [...] > > > > > +struct alloc_tag { > > > > > + struct codetag ct; > > > > > + struct alloc_tag_counters __percpu *counters; > > > > > +} __aligned(8); > > > > > [...] > > > > > +#define DEFINE_ALLOC_TAG(_alloc_tag) \ > > > > > + static DEFINE_PER_CPU(struct alloc_tag_counters, _alloc_tag_cntr); \ > > > > > + static struct alloc_tag _alloc_tag __used __aligned(8) \ > > > > > + __section("alloc_tags") = { \ > > > > > + .ct = CODE_TAG_INIT, \ > > > > > + .counters = &_alloc_tag_cntr }; > > > > > [...] > > > > > +static inline struct alloc_tag *alloc_tag_save(struct alloc_tag *tag) > > > > > +{ > > > > > + swap(current->alloc_tag, tag); > > > > > + return tag; > > > > > +} > > > > > > > > Future security hardening improvement idea based on this infrastructure: > > > > it should be possible to implement per-allocation-site kmem caches. For > > > > example, we could create: > > > > > > > > struct alloc_details { > > > > u32 flags; > > > > union { > > > > u32 size; /* not valid after __init completes */ > > > > struct kmem_cache *cache; > > > > }; > > > > }; > > > > > > > > - add struct alloc_details to struct alloc_tag > > > > - move the tags section into .ro_after_init > > > > - extend alloc_hooks() to populate flags and size: > > > > .flags = __builtin_constant_p(size) ? KMALLOC_ALLOCATE_FIXED > > > > : KMALLOC_ALLOCATE_BUCKETS; > > > > .size = __builtin_constant_p(size) ? size : SIZE_MAX; > > > > - during kernel start or module init, walk the alloc_tag list > > > > and create either a fixed-size kmem_cache or to allocate a > > > > full set of kmalloc-buckets, and update the "cache" member. > > > > - adjust kmalloc core routines to use current->alloc_tag->cache instead > > > > of using the global buckets. > > > > > > > > This would get us fully separated allocations, producing better than > > > > type-based levels of granularity, exceeding what we have currently with > > > > CONFIG_RANDOM_KMALLOC_CACHES. > > > > > > > > Does this look possible, or am I misunderstanding something in the > > > > infrastructure being created here? > > > > > > Definitely possible, but... would we want this? > > > > Yes, very very much. One of the worst and mostly unaddressed weaknesses > > with the kernel right now is use-after-free based type confusion[0], which > > depends on merged caches (or cache reuse). > > > > This doesn't solve cross-allocator (kmalloc/page_alloc) type confusion > > (as terrifyingly demonstrated[1] by Jann Horn), but it does help with > > what has been a very common case of "use msg_msg to impersonate your > > target object"[2] exploitation. > > We have a ton of code that references PAGE_SIZE and uses the page > allocator completely unnecessarily - that's something worth harping > about at conferences; if we could motivate people to clean that stuff up > it'd have a lot of positive effects. > > > > That would produce a _lot_ of kmem caches > > > > Fewer than you'd expect, but yes, there is some overhead. However, > > out-of-tree forks of Linux have successfully experimented with this > > already and seen good results[3]. > > So in that case - I don't think there's any need for a separate > alloc_details; we'd just add a kmem_cache * to alloc_tag and then hook > into the codetag init/unload path to create and destroy the kmem caches. Okay, sounds good. There needs to be a place to track "is this a fixed size or a run-time size" choice. > No need to adjust the slab code either; alloc_hooks() itself could > dispatch to kmem_cache_alloc() instead of kmalloc() if this is in use. Right, it'd go to either kmem_cache_alloc() directly, or to a modified kmalloc() that used the passed-in cache is the base for an array of sized buckets, rather than the global (or 16-way global) buckets. Yay for the future! -- Kees Cook