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 DFFE1C48BEB for ; Thu, 22 Feb 2024 00:25:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4BA086B0074; Wed, 21 Feb 2024 19:25:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 490796B0075; Wed, 21 Feb 2024 19:25:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 358E06B0085; Wed, 21 Feb 2024 19:25:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 250386B0074 for ; Wed, 21 Feb 2024 19:25:08 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E3E8B120C46 for ; Thu, 22 Feb 2024 00:25:07 +0000 (UTC) X-FDA: 81817545054.29.6927CEE Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by imf11.hostedemail.com (Postfix) with ESMTP id 836C140015 for ; Thu, 22 Feb 2024 00:25:04 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Q9kVhtnG; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf11.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.172 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=1708561504; 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=WrVxGxFZ9H3+hlcYIVohDlCBqheEbLY5A8SDm36k8gU=; b=qRbQxUKiUuSRept0kfJePVcnEOnUnGARNR9gpxdoaiuCh3HDs9U7QcNrdsWEVpJ7wUUrxy 7eVIrAipfqp4g0H+hml3LLG4nhsFk8WMxM2vwgfZo+0DT9x8oPXWJKvrYXqGpGbHzIwuhO 3lq3bCOr4X4X6dBq5Imx3B5xBvb2xwI= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Q9kVhtnG; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf11.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.172 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708561504; a=rsa-sha256; cv=none; b=ULjJIVvYPhno4QTDCfYdSZWpCc0qjDG6fGuiOD3G/q5hamQmoeocAnlxyc7h7Njk4MsOwO x25rpLv+1PatkvdVMd49KJbFydV1TGnSeVlQm/kez6wjVoikbkDHP6APicB+1uHk3VadYn mfxB0bar0PAC1qPhRRAaVWCK1Vj7ECE= Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-1d73066880eso68935045ad.3 for ; Wed, 21 Feb 2024 16:25:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1708561503; x=1709166303; 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=WrVxGxFZ9H3+hlcYIVohDlCBqheEbLY5A8SDm36k8gU=; b=Q9kVhtnGzq9cSD8pEQ/ELUVr3O4LbgQ80M1t3nNeAQHIQ2UjDpU5EAZgC+5+H1Y8IH iSmZ+9bXBVa52qFKX5+BB3TE5LB13MuJyv9Mphcp8hToVTPZqNiOZpyfBJbV1k9xe/1f FDkqQsbDnijpvfo06wB78I80da+9WpKhVxshs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708561503; x=1709166303; 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=WrVxGxFZ9H3+hlcYIVohDlCBqheEbLY5A8SDm36k8gU=; b=veBQyjBtqvWohTsSddJm30djnxetzp3KfddN46rF/iMHjA5N1EbxkGZqpWuG01C625 hBQNZBxxa2pDpXntPGOAHoM/q655x4e5BGM7qLtRbneof0rsJnsUzFM2juBo3wE3Tchf 7bSyO7TBoHa74P52p74BuUvRWO1Rud4/I2GWqoRYZlmVKX50MBq5YgN5xZnvsuRtOUG5 kZisMAyt91zwrOiNx+OGQgygLtxseLTST3+EygOpQb1ydatOZm7Y+KY0vq49G51KCdi3 h/ZsjmSvUQdVNZ8jAe3DGNIsxMoa0tl8VbqvljxJivX48UMRgOzOp2XAmjWSq7vdKRZB hf6Q== X-Forwarded-Encrypted: i=1; AJvYcCWODAYq7lU+tkQikN3tdLwLpdMtJdshMQs5K2XkkduvBywlCg7NXsL0kEf+3eTnC60FfYeZocSMB8yE6uTbIb+DQE0= X-Gm-Message-State: AOJu0Yyu+iVmC8lIkzRZnW4hOsX82Z/TeFwmi0/cUnYpMHPRKWRcwUt+ xhM+vLha+CqdtuhWqNT90gXPMQeP4jb/MKoiH/VsDlG6VX5iFOH8ffG6+OFiwA== X-Google-Smtp-Source: AGHT+IE8cuZgqhfiFvIoQVgWdCedFdQ8RHOGePUqeWeLlVbb4CnpvNn3n0HXg8MMQ7Sn2woXNuUGhA== X-Received: by 2002:a17:902:e5c3:b0:1dc:87:855f with SMTP id u3-20020a170902e5c300b001dc0087855fmr11196593plf.28.1708561503247; Wed, 21 Feb 2024 16:25:03 -0800 (PST) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id li4-20020a170903294400b001db7e3411f7sm8727330plb.134.2024.02.21.16.25.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Feb 2024 16:25:02 -0800 (PST) Date: Wed, 21 Feb 2024 16:25:02 -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: <202402211608.41AD94094@keescook> References: <20240221194052.927623-1-surenb@google.com> <20240221194052.927623-15-surenb@google.com> <202402211449.401382D2AF@keescook> <4vwiwgsemga7vmahgwsikbsawjq5xfskdsssmjsfe5hn7k2alk@b6ig5v2pxe5i> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4vwiwgsemga7vmahgwsikbsawjq5xfskdsssmjsfe5hn7k2alk@b6ig5v2pxe5i> X-Rspamd-Queue-Id: 836C140015 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: ogzg8muskhd81j5ykua6d5cbiwf7sb66 X-HE-Tag: 1708561504-259683 X-HE-Meta: U2FsdGVkX1/hU7DZGVZADTUnB7kTi0OPUm+9ZFHmB11ISlLK9j+aUa1jnR5hg+7JGjpSo0Xl59s7OGRJ7t0htcTr6IuUzo0uB47JPMnAPhSC63+OMvYk8u5bA3pXmAEtTb5l6jUFQo0Ux5FugNs7HWqwioRIeVPyQHRbm4No4ebEyj4O3JaVO9TnYMlHOsvb3xHRpmCeQ3PwDdWpFGubzbF5WVRQqPVyFx/TTVaCKz1GrXWetuQvRqN3JuwdzDabbmeyBgIyNTHpG2zHolqc/8LX6FUcpvv0XptpXW0I6vRdvNMaehglZyP9PF9CTFgf+HFOMp90pGquWex11KSB1EgHKCPOhLwoeIl/UWxC0f9I6PdVsEs7thsTimoonySjZlOfAiuf4jJBApMfSzwGXqM+ED3N7Vlp9p7oYYBu3qKYt5Bv7mVXhhJgd2Ki66NCtIMwp5sx9adUwjjJsUX9ICfItb4gyYw9sx09kZJj2MshniiPapnIao7wKQ+YbpAyvQWtxtLgi7BpzYb+d2i0OcmzgQ9p02ZFwQR+XyRjk55OjjcWz+GDI6CET8Y7XBR3pNUYWXf6Sdnzzt8u8XqvIibcX9HCvcSHfjS6r0h3MWNesKGMQbtzZlqZZflaDpQ1LFVtLLzO0pXbZET98qsVr9IRGr+/2LTeqyVzMVmuglfjh+Mxeiq6EXY546t+tDebTUVhxsQNGQRCAYZqznW9Z2EOCaptInVTrb2wbTgEY5HUYARy6w8q4MAQacA8u00jo9UvO1Nng/I9uc1jN/c+bLp1BoBYYCv8Qj6ki08somH339mcGuFV5kTa4AtrcMSDTkPx7teliiF5KyjLJuP393fikkh0x9kq+0EWmE1l3EKO/PZgLd2GG1DAdln5sVffjIaS5UHSKXnkVboDWT5nd4I4cxqxcBHhur4JE66i3BhpfG7MVH3BZiLQ5Ag8iG4pHhlhzXjcoFDrbjZjnRu T5rvNnLn 1CWypEGXb7ll6Sp2efCP5LDLDlNdeVC+cYytVnw/7SmvgMgyUpN9IuwdIRdpGisl/32lbjXxMy/E5XAi9/xDeY/AV/qHW6LXadM+nBoLshEJ/IzANMp5JYOJS37WewSQypThVkHWKjrQnrg2b4NyEpmqHcDCu+mVUphvk5BRPvPBvJ4fHEjq0+g1VFHwmalMjKlD4p2/je45ktGigT99ji4q/pdoakst8wXeHHmFPwqFC0jMxLdU+tujODIW2AzcaskagQY82yDA3YhtQmshNKkD776Qib4ya+lErGKHNZE0CdmNE4EDza7CHwYhqUmB/+ZZAzUD3TID+18Sc8GHpFy+qpdyAKiKguIFEVFzIvUoO9SScS/mdeGEcVaCNqfjYkOmam1B3ltTV1I2YGNVP6aina66ArnLJFMnJiqTP6/KwXyFpF8wQdDs0/Gk4WBtW+SLOvOY+a88Y6IusSsC/Xn9Qp6pIIYyN1EoPPWO7AldU+C4MK2FdIPjP+ZjNk0aheGU6MQndDpnyIaYTj9sA8icyfPGM1iCMlPhHD1bORha8CB6cczTEjJHhJ/4I/yl3BOXb0jt2BcnC1jnAFSTLTlztSkk8VVk+gBGUXDjaXhcQwITaEpF7GshNjmBvumm/hnfV+GJ0ywguddHApPjRqvil9jmInNmgihWXoc6cv0MiZHfNA17xl/ss3xEk/ZyGrikPJVTwIJcQGzvpjwffCiVmPNT5QY62DMjzsGW7trlYkg6KK8EYQ6oiaS3tOH0jEuP/3BOQjT6BqMTQvw4BmBHJ0jnkgWP9cub2z/4XbJwRQQippvKU6V5hpaR9GxAHIvNJhOgJfpThyO6dI5EJvxuYYjBJyvlEjt1zEXMl+Js122k= 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 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. > 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]. > and don't we already try to collapse those where possible to reduce > internal fragmentation? In the past, yes, but the desire for security has tended to have more people building with SLAB_MERGE_DEFAULT=n and/or CONFIG_RANDOM_KMALLOC_CACHES=y (or booting with "slab_nomerge"). Just doing the type safety isn't sufficient without the cross-allocator safety, but we've also had solutions for that proposed[4]. -Kees [0] https://github.com/KSPP/linux/issues/189 [1] https://googleprojectzero.blogspot.com/2021/10/how-simple-linux-kernel-memory.html [2] https://www.willsroot.io/2021/08/corctf-2021-fire-of-salvation-writeup.html https://google.github.io/security-research/pocs/linux/cve-2021-22555/writeup.html#exploring-struct-msg_msg [3] https://grsecurity.net/how_autoslab_changes_the_memory_unsafety_game [4] https://lore.kernel.org/linux-hardening/20230915105933.495735-1-matteorizzo@google.com/ -- Kees Cook