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 E7EE1C3DA4A for ; Mon, 5 Aug 2024 11:09:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 448046B0082; Mon, 5 Aug 2024 07:09:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D1186B0092; Mon, 5 Aug 2024 07:09:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 272396B0093; Mon, 5 Aug 2024 07:09:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 00F6C6B0082 for ; Mon, 5 Aug 2024 07:09:30 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id A4E6C1A1D9C for ; Mon, 5 Aug 2024 11:09:30 +0000 (UTC) X-FDA: 82417920900.06.4CA577D Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) by imf05.hostedemail.com (Postfix) with ESMTP id AF103100003 for ; Mon, 5 Aug 2024 11:09:28 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=187RQhor; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of jannh@google.com designates 209.85.208.42 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722856118; a=rsa-sha256; cv=none; b=Bco6FDGdj++4YFS1DPjC2VeTD/DO+/AWrcu+0Evp8u7aZo0pZ0asJgD67cP7qeDfNIi7Pv AFlBywwirVP/D3oizcUmTehzr11pBiIm4tiyaF9BcEXG9En52KnOS7ccyDvbVKoFMmlwCm hcK7bZaJs5GckHmNOBGCRRzFqHy9Hyc= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=187RQhor; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of jannh@google.com designates 209.85.208.42 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722856118; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=l4Lfr7cWJZWVAHEZdC4tIJBE0idMw63JeT0pm5BZ7xI=; b=dl5v9L3CNp+Xdm5wq/JYmZlokDl9NYp3MhWygT4ESIErungL0/HBHjQ7bXRFBWRqR/+NR9 7ETzYXTUXsazE/U7V2dSvt/U83EUxcPCTtB/2B4+d3SNVfW+DyDOeEPhyVp+7isz6fT8Zq ZK5JDq30kZw/rVM92DoXcIndnYpyZ4w= Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-5b9fe5ea355so10733a12.0 for ; Mon, 05 Aug 2024 04:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722856167; x=1723460967; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=l4Lfr7cWJZWVAHEZdC4tIJBE0idMw63JeT0pm5BZ7xI=; b=187RQhormejd91kj3tWyTF5TG3KS8s3C9w2sTh/EGnROi1pnvaPSY5ZXIzth4c/a+V 2EYdH2asvyH0pYa8v+yGv8mxPLpBszIH2b3PSD6lhvSaAsCMUx4/gjo9S5Ri0kI2reMy 8CsPNa+84EvPdROsLC1tytMCib7NJxxUsBOMq/tzs4qMGph07SZCRDVPESBpt1Ssgijx dgBQQZMaLCc/782bnPfjr9MJyY58FJO4T7N1kC1KcpstLaXV+JX6J9Cz6R519y4QX2NI hDeoYW91C8zA0tGH/htlwRbq/6UoFlnB+uj2ExCmeNSthEPShoFjiulfi/GaRT7MahLm V1RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722856167; x=1723460967; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=l4Lfr7cWJZWVAHEZdC4tIJBE0idMw63JeT0pm5BZ7xI=; b=CbKkfIMPXDmY7cdVmBpFPT2lU+JzDP4MekQg+Kx4J6/06iOAr1Uiwe2kgy6u8Ni104 1Do/O+BXTdVqtSTlpnyt02uL9S1t0iv2WEwvctbuXHRF6n5oCI9VxXOVEUCaLKGbr0hi L/wTH0Zh5glLyIJN7WHzXZpKfTJmA5KLE3sRc6DzjB/ETrma7Zd3c28Ncw1A//M3yxHD K2yTIm7v4Z49nrA5b6KjNfpt63hXpdysMhHe9vlAXSiRcbvT1KVZ4luXXb7St3Dy/nUg hxAyY4jexZXqEyQ/7KOx+ffKbX5jHoAqjvqpshFc2fwhoWMc61EfmCsl4U8HXgTFOpdS EgEg== X-Forwarded-Encrypted: i=1; AJvYcCWAhPLqcZGknAC51Gjp0d9SC3ogx011HfoPYzalldxL4zT5ELV67M4BzDlJpv+7d32jxWsypFEnOG1rrN/Nb35IB6E= X-Gm-Message-State: AOJu0YwBjUun6Ij3gYLtDyxD9n9Vd86c2B0cUskpK/WJAfq1KCXVws32 8NZMm1jJoMaSl2Xku9b0mJfT1r2vtrsx1+Q2gT/VCVw1++jPrDqAQUXJQ3rcN0RviOO/77JLplF c59+nedQhNz9aZqTq5K6U+UVXPgitOQGJpT7n X-Google-Smtp-Source: AGHT+IFp87Hdx6GUQ1S1AEPzYYlgjbHanaDmgkICP7MLibR3DnxI+KS0tbUjMlWb5jGpuxF3ieM4UF/2QwlapV8GnpQ= X-Received: by 2002:a05:6402:35d4:b0:5b4:df4a:48bb with SMTP id 4fb4d7f45d1cf-5b9c1e5e74emr228803a12.0.1722856166424; Mon, 05 Aug 2024 04:09:26 -0700 (PDT) MIME-Version: 1.0 References: <20240802-kasan-tsbrcu-v6-0-60d86ea78416@google.com> <20240802-kasan-tsbrcu-v6-2-60d86ea78416@google.com> In-Reply-To: From: Jann Horn Date: Mon, 5 Aug 2024 13:08:50 +0200 Message-ID: Subject: Re: [PATCH v6 2/2] slub: Introduce CONFIG_SLUB_RCU_DEBUG To: Marco Elver Cc: Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzbot+263726e59eab6b442723@syzkaller.appspotmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: AF103100003 X-Stat-Signature: pifrz5a4zmwunff6wzsfo966pck8ip19 X-Rspam-User: X-HE-Tag: 1722856168-983570 X-HE-Meta: U2FsdGVkX19pb2xR0v7X0oxH6Bk7TUBxwGeUsh9xAA0gJwsMN5dXPCynmX0+QF/S4ULR2cMnf+n0mKMag2v1umviFownHhJ1DnrAdskrYPis26K3t9XyepHRv0QXm4ezFVKXre79K7PcuU4LZz1LkHBAh0ecVkCNAzNsBF3J3FPKF6Xi70iRsCPpqifH02IJdRN3qATTRhhCjDD4XED1/eoLTAdjkjsjYvzKVk5xlP5w6890nnkNyhaWw6XxL1X0Gy7n8oPQXb7PY97IbMt9mIG0cD+v5kQpWIt+1rG4HMADZDH/jwL2mmJD+5RlRojE3dEm1UI/grupXvK8N7FVg6/n+TPiHnzgGghCadRHiX4BW7VtETDgf6/T93yBF7D7Cl73PkP2ef0joKkSS6ud6umFo07SEgXIslQ6ueRWuzfNh07v4Wuzy5xn4BAZnRz4Iq10zfMW1jU8+vVZZcks/MN6llrSX6oK6CnGI9E34z46dfS7LnNE9nr6ph+J83p8Yr9L0ORgTStOeEvNhGwlgI1l1e7oJharZnwgkqJfuqNjvd0MwRCa67PlmCAUbhXjPAO3uDjTFwDEhfacp/quGoT5HBbH2wBQE+YgqZkomi7SD3GVyREDD+291BPpJRy9hzawjo4Ea/Vg/Lxflb3jWrFNbBJWvp27CWgv3jIFeWkIL55mw/b9FWcgWbAWjEY90gUJNdPaML4vs0c/Ay8mWApQuESxQhNj37wxZbLdoMiiMS+Dk1DpRwU7wfB2LDu6hwhodJNxQm1lbZZLZjrbqIyI2VIt6KXeQhRu0ym48Trp9+354ps14CT5DKvXr+kzWbPZcgbYQsTi4a0THpc9fxOO7I9PsHqt+NrgqzRS7RjJRlTSgCGN4jJxsFYMqoklhW/bBhhbR78L5wNEJ/vsh6+We2+Xk0t2zBe2IGkx+9+L7qyOK0qmC8N00DEfAxKG8Qs3BzaS4RIa3ZA76B6 hGIKWqAB Mygl46+QVwGm8LWRansP1XA9SxJV8iCok5VR4el9P8RUYZRiuLPBfM2G+oiqzf+Xc/eCBUlCR1oiauOZoMVP9YS2Y4TLjoZrbuPHIXZh/1gJ29tFiaB2AMGx7UW4ur75HWCnWNY7p/02d/B3+vFkz+HGOAOsbPrpP4c1I35hNfqMfhryfwwBm6LYzyRa/ZBgXWeLsbsmVQMslsXmxgjPl20I101FMpG7nlh7q4RVpJjyhJlLwjFXxLS6RxLwiq/bN5jA5h5oTSsT5RLomC+aMUzDUemAIfXEshUHKM3SXrPDI2O7cSmf4Diz+ROMrWuD1elAO23J7Fi/K/OpddLavTeF1EFs+l3xO9ZWrJLlNlC46PQsd1DgYB17bpw7LZGryKlUdZDv10htj2FM+R2O9kPGTw7P/3pRjO0ReZmNvk7fIx5lC2p6W7zqdMdnjtqVU6aFpPIrTfJgYmnQ8+SMShmTPg27OMNQZnFs/e2F9wybgUOFqzBbgo5r5EDaZCANhe6Ux 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 Mon, Aug 5, 2024 at 11:02=E2=80=AFAM Marco Elver wrot= e: > On Fri, 2 Aug 2024 at 22:32, Jann Horn wrote: > > > > Currently, KASAN is unable to catch use-after-free in SLAB_TYPESAFE_BY_= RCU > > slabs because use-after-free is allowed within the RCU grace period by > > design. > > > > Add a SLUB debugging feature which RCU-delays every individual > > kmem_cache_free() before either actually freeing the object or handing = it > > off to KASAN, and change KASAN to poison freed objects as normal when t= his > > option is enabled. > > > > For now I've configured Kconfig.debug to default-enable this feature in= the > > KASAN GENERIC and SW_TAGS modes; I'm not enabling it by default in HW_T= AGS > > mode because I'm not sure if it might have unwanted performance degrada= tion > > effects there. > > > > Note that this is mostly useful with KASAN in the quarantine-based GENE= RIC > > mode; SLAB_TYPESAFE_BY_RCU slabs are basically always also slabs with a > > ->ctor, and KASAN's assign_tag() currently has to assign fixed tags for > > those, reducing the effectiveness of SW_TAGS/HW_TAGS mode. > > (A possible future extension of this work would be to also let SLUB cal= l > > the ->ctor() on every allocation instead of only when the slab page is > > allocated; then tag-based modes would be able to assign new tags on eve= ry > > reallocation.) > > > > Tested-by: syzbot+263726e59eab6b442723@syzkaller.appspotmail.com > > Signed-off-by: Jann Horn > > Acked-by: Marco Elver Thanks! > Looks good - let's see what the fuzzers will find with it. :-) > > Feel free to ignore the below comments if there isn't a v+1. [...] > > +config SLUB_RCU_DEBUG > > + bool "Enable UAF detection in TYPESAFE_BY_RCU caches (for KASAN= )" > > + depends on SLUB_DEBUG > > + depends on KASAN # not a real dependency; currently useless wit= hout KASAN > > This comment is odd. If it's useless without KASAN then it definitely > depends on KASAN. I suppose the code compiles without KASAN, but I > think that's secondary. In my mind, SLUB_RCU_DEBUG is a mechanism on top of which you could build several things - and currently only the KASAN integration is built on top of it, but more stuff could be added in the future, like some SLUB poisoning. So it's currently not useful unless you also enable KASAN, but SLUB_RCU_DEBUG doesn't really depend on KASAN - it's the other way around, KASAN has an optional dependency on SLUB_RCU_DEBUG. [...] > > +#ifdef CONFIG_SLUB_RCU_DEBUG > > +static void slab_free_after_rcu_debug(struct rcu_head *rcu_head) > > +{ > > + struct rcu_delayed_free *delayed_free =3D > > + container_of(rcu_head, struct rcu_delayed_free,= head); > > Minor: Some of these line breaks are unnecessary (kernel allows 100+ > cols) - but up to you if you want to change it. https://www.kernel.org/doc/html/latest/process/coding-style.html#breaking-l= ong-lines-and-strings says 80 columns is still preferred unless that makes the code less readable, that's why I'm still usually breaking at 80 columns.