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 95C39C83F12 for ; Mon, 28 Aug 2023 14:40:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0D90E8E001F; Mon, 28 Aug 2023 10:40:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 089618E000E; Mon, 28 Aug 2023 10:40:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB9F28E001F; Mon, 28 Aug 2023 10:40:13 -0400 (EDT) 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 DAB888E000E for ; Mon, 28 Aug 2023 10:40:13 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id B6FB21A0260 for ; Mon, 28 Aug 2023 14:40:13 +0000 (UTC) X-FDA: 81173773506.03.18A78BE Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) by imf12.hostedemail.com (Postfix) with ESMTP id EC3D340018 for ; Mon, 28 Aug 2023 14:40:11 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=vFxOzp+8; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf12.hostedemail.com: domain of jannh@google.com designates 209.85.128.54 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=1693233612; 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=j2UbLxhYqoo5RujlArsNRFXdGVrlcSizT9E5D+JEpAc=; b=mVvghDipJyg127czLPynE5uZ5tCAB4IDPwShS/Bu5I1QS05AOpJ5OguyTG4lTpKh0GXgeL 4bipl6Jk/V1zQp16KhLjZarzQz5ADEIHUb5k9exMWfCk75SeKtL0tFI0J1syEvHfoSuBtS hs5cE2bF+l5U/9vI6LpU0p3etyBT0d4= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=vFxOzp+8; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf12.hostedemail.com: domain of jannh@google.com designates 209.85.128.54 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693233612; a=rsa-sha256; cv=none; b=XEHSoRRQoSiPz/Fn6lLbCqPT/Q3dcte19g9b5KiiY4Q9Yq8faErD6WqoPrfE2FWQtOdKAu 3LAy5bGlfa3LUV4USStNcJikymcJs0nFAxM6QHzB94SxH+R9nUoD8pQnPKEAwRmO/t6zSz CPQ5dSXUu1q/3b8ct+BhNACbzlqOpuU= Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4009fdc224dso107215e9.1 for ; Mon, 28 Aug 2023 07:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1693233610; x=1693838410; 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=j2UbLxhYqoo5RujlArsNRFXdGVrlcSizT9E5D+JEpAc=; b=vFxOzp+8wXjtPznOVRFbsFACAvF8Fn1O19/xbw1G8HfK62K2JQtl9ds8D5nFh7m1YK F6+diA6BqR6j90u4E2EZs0FtxBgc2jjm/FBjehLMjNtXKP7EnBAlrxxupFyvuo/jQsCv N8gu+iB/v/QtCRuLLsZvNyKU02g/uFsJ8N8+xvL5wfVAlukSy2gmY3zUOAvN/W5fwz69 hb+4a4bLOTfoVnkSoHNyCUUJkJVOlrviZB3Fsybwpl/TEA2XcMa1g2ETyzJ84AE8L659 yvhhjML7YKgLCtExddk0uCQkeSkw275uKdWgCNudm949iQ85Qp229cQwGNmlpwWPkECa sfpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693233610; x=1693838410; 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=j2UbLxhYqoo5RujlArsNRFXdGVrlcSizT9E5D+JEpAc=; b=GbQIetTxXQ3jCzitcZ621/P+0Il2449f7yEj/cqeCi6nOcBAGf6SCxM9EUIeldsocQ +FS12/8fyLgtDDEmCSjjdF7AO6afFuv+YLFVRRCnPUKCwMg4WlqZUDU4+XI+Lw4hkSP/ 38JYoA8DrUUtR0KUXbNGN6XHqh4wCLYcgAhexeTte85OrgDW6YaUvW8otpcrbqtxB/KZ Nu9W3/D3fCbusjbb6t2smn05LEK/C5+/sz/VeFWN8pssifs0aQXEqHwT669SGOgQnAdS QnYTZ0sOPk3kzbGYVolkuSfiC+7jjpa+QOrKWfmucKMKR3XfRHznh9NDj39innFGcqKR HF4w== X-Gm-Message-State: AOJu0YzaAryMVSukSjiYY+MCyKFPJ3qhlaTdbNMWa60uKd27c9bVc72u hgyr6s7c0+3k8WCQrq4P0QZgoEFsdh5JrZZD3rSH2w== X-Google-Smtp-Source: AGHT+IG89PQvGlyyexU2ilvXeGop6BLWwAi3Qpxw0oEo0DLUWmBEPba4+VZw3sP1uOUhmoGBub9dfKhA7O/cwHW0Vho= X-Received: by 2002:a05:600c:1da6:b0:400:c6de:6a20 with SMTP id p38-20020a05600c1da600b00400c6de6a20mr306793wms.3.1693233610358; Mon, 28 Aug 2023 07:40:10 -0700 (PDT) MIME-Version: 1.0 References: <20230825211426.3798691-1-jannh@google.com> In-Reply-To: From: Jann Horn Date: Mon, 28 Aug 2023 16:39:33 +0200 Message-ID: Subject: Re: [PATCH] slub: Introduce CONFIG_SLUB_RCU_DEBUG To: Dmitry Vyukov Cc: Andrey Ryabinin , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , Alexander Potapenko , Andrey Konovalov , Vincenzo Frascino , Andrew Morton , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-hardening@vger.kernel.org, kernel-hardening@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: EC3D340018 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: x1kp6jwcp4pupi9wtiirp9uesb51676z X-HE-Tag: 1693233611-443747 X-HE-Meta: U2FsdGVkX1/vrsJFUWOY87lxe3r74aEb3YYmFrSt1OZw0GfrsAzDbINGOjloqvRiUeeFYk9cEcNV7wfhTGz6VHYyEbuukkdcLUEQQcg8TYniyPzO5KcDgSUehA5jfhd1UBRZqRL5G1FK4jx4nOG4wwhZfk/+kSefX6mHuyIGFow9i04fUu6YmkldAkzIzMQG8NbGwuoZpHdDVK3g51ibQZQ/TcdiSndd9YZ6EXIWJeb6c6kvCBE8ug4of0yisnq9XDvLNV1KMtaDI5NH3Nw2Refb3+8NNgwJZmfyTapw3muhmNscB7Op/r5ZkJkbmdwRWhBREfM2zs3Fx9f8QZWgplvD84xQH9yXI4KfKlEgdT+RN55lirya5ydxrXCW3gPBk1lN8k56QAeXqVT7KNJ+PUhT651NB/gL3TemkkNjgcOxcIdZOdZCkHrB0S2FGobB+1Ehwisu3meAXrN5w5YUtxU5sRtzWmIa3O1qcuj45TnFbtRaSvKdopYwLiN4Zm5x+h6j8YiJOPtI8FoC0Fx6jnnZRomsgyQuTmdgWN6fZxg9pLb9yu687OoLZ0LBC1mSYe/yeiekDCCRRUwZYFwkV/gmjbjscsbRmHWt5Cxy/mh+nOgVlI1UMktG1W1arjpq110bImmk5T6SBa7Qq7ikR5vGhi8YxVHlj/whwdyRbajnSIaxa0cylnLn8D2J+Pm0BgMUByKlwER8HI/ZtB4BcHe79ICE9VJkMiIBl/Xl34p2lkzf04ZQ6+DXsgNJrXUdSDuNXg/pvaS4AvhKJUReHFFYJNSdLyUc8XdC/a7hAhIkNc4WnQu9sePSdonvu5ZiI8fi2E7m5MbQA33M+EqQPas1J2Vr0+vQ7Bq0B6UVh3QEITtmxHcPp+UD7cSuZD/g01XYveQcNl2+jnLJWStmVphhdHTPALntbqyxdko8h6d84hdVgm/047whb9HpXimm0n0rNVFC53fFMGkS3U4 KSEyCxVn n1K4FtEKSWFQ2b48Gqw7wYkxMlAhZCRFXDHSp0qbKahfq8RHbknGBNazLpNSG5Fp2hWxDjuHWjKNe+ue2uVoD5p1nNe3R4ANmPtUSPxsWFT3JLXSLtEfJtxEs+jUh9tQPqtQaly91187bMu8sLbZKKTgDEk28aYNwzfZzyUrz3Rg2wT3dLuxrw/eTWcz4TKv69r4LbO9fi0QsQQ8tWCUhCe7rahRwAENDs8hcK/MRrXmWh1mudqxrgX9JFrjZmTU2HYO5KpV4NqhfzH60LUggHFlUAz6nEAa6iRn30L+v0zflxtvcilJCYGtEnZFZTxPzh/f16t5bEIZf4gtE7Vm8WpXT+ciwWb/Hz81rpIRmXde1TaM01w2VqbpBDA== 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: On Sat, Aug 26, 2023 at 5:32=E2=80=AFAM Dmitry Vyukov = wrote: > On Fri, 25 Aug 2023 at 23:15, 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. > > > > Note that this creates a 16-byte unpoisoned area in the middle of the > > slab metadata area, which kinda sucks but seems to be necessary in orde= r > > to be able to store an rcu_head in there without triggering an ASAN > > splat during RCU callback processing. > > Nice! > > Can't we unpoision this rcu_head right before call_rcu() and repoison > after receiving the callback? Yeah, I think that should work. It looks like currently kasan_unpoison() is exposed in include/linux/kasan.h but kasan_poison() is not, and its inline definition probably means I can't just move it out of mm/kasan/kasan.h into include/linux/kasan.h; do you have a preference for how I should handle this? Hmm, and it also looks like code outside of mm/kasan/ anyway wouldn't know what are valid values for the "value" argument to kasan_poison(). I also have another feature idea that would also benefit from having something like kasan_poison() available in include/linux/kasan.h, so I would prefer that over adding another special-case function inside KASAN for poisoning this piece of slab metadata... I guess I could define a wrapper around kasan_poison() in mm/kasan/generic.c that uses a new poison value for "some other part of the kernel told us to poison this area", and then expose that wrapper with a declaration in include/mm/kasan.h? Something like: void kasan_poison_outline(const void *addr, size_t size, bool init) { kasan_poison(addr, size, KASAN_CUSTOM, init); } > What happens on cache destruction? > Currently we purge quarantine on cache destruction to be able to > safely destroy the cache. I suspect we may need to somehow purge rcu > callbacks as well, or do something else. Ooh, good point, I hadn't thought about that... currently shutdown_cache() assumes that all the objects have already been freed, then puts the kmem_cache on a list for slab_caches_to_rcu_destroy_workfn(), which then waits with an rcu_barrier() until the slab's pages are all gone. Luckily kmem_cache_destroy() is already a sleepable operation, so maybe I should just slap another rcu_barrier() in there for builds with this config option enabled... I think that should be fine for an option mostly intended for debugging.