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 937F3C2BA18 for ; Tue, 18 Jun 2024 15:15:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A7818D0030; Tue, 18 Jun 2024 11:15:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 157898D002C; Tue, 18 Jun 2024 11:15:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F39DC8D0030; Tue, 18 Jun 2024 11:15:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id CF6DD8D002C for ; Tue, 18 Jun 2024 11:15:56 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id ED6351222CB for ; Tue, 18 Jun 2024 15:05:50 +0000 (UTC) X-FDA: 82244334060.23.124DB36 Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) by imf30.hostedemail.com (Postfix) with ESMTP id 0387F80030 for ; Tue, 18 Jun 2024 15:05:47 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=RAvSi7WZ; spf=pass (imf30.hostedemail.com: domain of glider@google.com designates 209.85.222.170 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718723141; 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=fy3M/AH6/xybCaot3WBwIJpFavAawHNjcL6fl3GGJgo=; b=D1cgs1NThBPHTOZtnUb7yn93x7S4MY7tUvbSlzGnbPPzXe0KIcpKjGRUEOtTLLcBnozRMv FVQDYNRqb0cKlpmZdnSrlQQEOGHxmUhe8+dapk0SDRFrm6MsjjOak6tVUPyD7PwmwuxAwZ F1MhOLea/l52EaK94aV/6c1lJmifMVw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718723141; a=rsa-sha256; cv=none; b=Q5X5Mrnid994jbMi5ovsyYkILpInQLr+/LhdtF/Bhfz/Nl+14zFFytPjeRnYvFZ5QTMrv3 l+8HWCIDR10RhsQnvgd1NS39yyGaUGtQ2OUZD047J38G1HGbInewaE3oR6KR+gFojs/Fr3 8A1sTyi//MdganJd2ylixCM1VbVHDKE= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=RAvSi7WZ; spf=pass (imf30.hostedemail.com: domain of glider@google.com designates 209.85.222.170 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qk1-f170.google.com with SMTP id af79cd13be357-7971a9947e6so292707085a.3 for ; Tue, 18 Jun 2024 08:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1718723147; x=1719327947; 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=fy3M/AH6/xybCaot3WBwIJpFavAawHNjcL6fl3GGJgo=; b=RAvSi7WZD3lN7lv6LWp+7bNxcXlnKgPWFmjJ1Xw8GpXwEbrLTxXXchNF7488+P2xXp sjYV3/iRfaTcSDqm2NKf7a1IqQ5jQLqGKZ/AnmPeL/AVjeWF61YWE+5fDFxv8DjCE+1V Fz7leejwjM+VGVk53G/u3rg/Yn80XkEkeqco1RpEgB4MKKLVxGUEO2H1nspMDX2Q8pgP 5gqZ258CvhnFfAnHWwl3AVsv+y42kAR48xTBS/nBJd5PRSskK+XeilJcSJbjKtNsHWyQ 8ycwD6FOeCvL0DDFj+T8yfrVg+gOnBV6/xKFdoZkSP2UFSJ5IuqaxEgChe8MKHkWRuMQ PWTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718723147; x=1719327947; 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=fy3M/AH6/xybCaot3WBwIJpFavAawHNjcL6fl3GGJgo=; b=MHWrg5SmDvTdgJuKyd9ylZqR1bidIZAWFVA5FFMYpYNSewP8aQFbIu8hXNOFaKJCs+ FuOYs5NbXvCLWbBC0XyJxUOUgxAaKizWBePOIUI5daBkY7Mq/VExeA3GPAj3rrHyYWrs g17b4hg0MIVe4bVmMP4PvHHYozTzyG1uV7mppy55aL8qiegz71+K+eZHUbrZKj2OaBAG ZhqRd5J+nR23T9Um0YFfCH6r2qb9ywlSSRpDqZgH45OT+amMG6S3CvTpAGuFp2RKziIo Zl0R+tog9eQCbtLyEyQ4Pf33H7/EV8SvtMkZyfxLt6ckABjkISwJYtl4XGURLYhO7qM1 BKmA== X-Forwarded-Encrypted: i=1; AJvYcCXnl5QBfqY+qIznRglefPDjYrq3PrMlqHqBSqGsZgvrsB7fTz6PerdnX+Xjvt/ZM3NvyxSjK2Ge5bSex6yKRc9CaxM= X-Gm-Message-State: AOJu0YxtdExqC3htTcfZoHMAmd0DEAfO2S4KfvMpJNA2CJ/iw03LZ8tA uGzPnR5qis7ac8w8cqhwE0UJYKqeBYaqqDOtDRDrUFgNhFf1PS07T/guqcpIpel6bUtBZi1rVCD NiTS5Op+PzYHO0cmOqSDn0rztS3esz/8/5Cky X-Google-Smtp-Source: AGHT+IFa6FCBqd8D9Nj1JaNGKSLtJBvp/bRoyV+oAG2O6vNiHQ1JuiqvjZSAmr21MMQcuWOKxcWHb2lgAwdr0eNcVzw= X-Received: by 2002:a0c:df02:0:b0:6b5:61:53a9 with SMTP id 6a1803df08f44-6b50061578fmr5936766d6.28.1718723146610; Tue, 18 Jun 2024 08:05:46 -0700 (PDT) MIME-Version: 1.0 References: <20240613233044.117000-1-sj@kernel.org> <5a8a3c85760c19be66965630418e09a820f79277.camel@linux.ibm.com> In-Reply-To: <5a8a3c85760c19be66965630418e09a820f79277.camel@linux.ibm.com> From: Alexander Potapenko Date: Tue, 18 Jun 2024 17:05:10 +0200 Message-ID: Subject: Re: [PATCH v4 12/35] kmsan: Support SLAB_POISON To: Ilya Leoshkevich Cc: SeongJae Park , Alexander Gordeev , Andrew Morton , Christoph Lameter , David Rientjes , Heiko Carstens , Joonsoo Kim , Marco Elver , Masami Hiramatsu , Pekka Enberg , Steven Rostedt , Vasily Gorbik , Vlastimil Babka , Christian Borntraeger , Dmitry Vyukov , Hyeonggon Yoo <42.hyeyoo@gmail.com>, kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-s390@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Mark Rutland , Roman Gushchin , Sven Schnelle Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 0387F80030 X-Stat-Signature: rbf9m4jeimcc63uhbrfjsze6gjctcjgi X-HE-Tag: 1718723147-908284 X-HE-Meta: U2FsdGVkX1+rxy+f/hUftCwCFVEGogsCsaAD3xh+jompeNh0+5IXwGyo5LulJlXHcoJhkXAf5EmWwE++siXzCzJaSl0Kr48fp1bnsKy9rrCZOw0tq14H4jXQUhiF8O6RRSGaGtWG/0/Cqfc+/EFPYTQLdiv+Wc8GfGkW744oS6qZ+jt3Fc8+lbJCCw0BaI9yx5Qfzb8KtIBshqAQhG5In4v+s79ssWvBct+Y/7iQA3Ghfi9TpiPq6gOtBgeP17EafMHss42LvysX5eq6K/Dv8ewuOHVUb+L72C6F7BlvNt+p16Jekg39gkUiHdzq34VItb8r1PdORo3RIIO8RoVYY6px2afDEws5gdM4opfTQu5dgbHzG6CeFpGzvWneLXDiylLmUkgGCUMV11KgAmpzUwwzwjtAC5HdQhlhCfs4rp8aNwbzdIXXT5suNpPHOxIW+LkQzhUrNb/zTwH8N9OGaQ38UA5QWgQnStu79pP+LPdpbeN9LeGQSv/PdK4DA7k5Bh3rmqJKZoV6Vq9rUHXMj/IYvuBcSmoEfW6Cd8s/DknZOZeXstCiYiGFOPos7o/65vaooXiQg4WHj/+1bNzZYe9DK0tcSjXnmxAGMxsXfqOU3KBbFRbb2PYNKRukrw6pxqOpEnnCftE2DyE3bb+wMCt/APRNth+ZYhUW4FWEpukgZcycM8QZ3zQ1+50FvreLzaKw9ZLBKPTr9klZthYA35jf4Tc9eS0bst7WkzuA0HYDTvwKsgkV5Z1AMzDcZdmQXWRFA/72I0SugAM1VNWb2FSGyTGWYRL1PFKsx1/lRMlci9nlmtamnEp1Yn7gar8ap9ZJsXqlyPdquU7A7XPhMGHh2taSawspKL0zHtq+NsYxNXTbLIQFFPVPjykqfySi3qWWTBZ1P9mFlHxU1Fua4SKabjBLQoMvLgi/tDCAVdeEP0C+89+yMy3IHW6rS4umi8gnJg3wHCDTXT9d5WU GMBO1apB iDpld/hb4ytogGN8yciCbnbeXf2o0SNW8qjc/WUIphwQiD69DXiC/PGHyt4R9X2Qd1s59vzPD0e5OhTSmtWi+tpuUWDBsWOtQVtob1cLy414wKx09uWzVWWic4vIc5i+VaXkIfzvOoTLjbN7nQFAWe+ppx9KWNyiRP4KiRXSSFmxMUj2t4F0IfaeIYd6dlSc6fELuUE4RVP0wLE+KUShsIqEX3o4S+wGKpGmh+LG/jFpwz9NqqmCu1pqkQHe0W7onVuzMXY1qZIh+vosbXmTimn9wNv7P31DyZ9apKX4Zrq+VcXh3KP0Bl/9nbJWty3njApu+O+y0vnL1IDKvSnndgL5RVg== 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 Fri, Jun 14, 2024 at 1:44=E2=80=AFAM Ilya Leoshkevich wrote: > > On Thu, 2024-06-13 at 16:30 -0700, SeongJae Park wrote: > > Hi Ilya, > > > > On Thu, 13 Jun 2024 17:34:14 +0200 Ilya Leoshkevich > > wrote: > > > > > Avoid false KMSAN negatives with SLUB_DEBUG by allowing > > > kmsan_slab_free() to poison the freed memory, and by preventing > > > init_object() from unpoisoning new allocations by using __memset(). > > > > > > There are two alternatives to this approach. First, init_object() > > > can be marked with __no_sanitize_memory. This annotation should be > > > used > > > with great care, because it drops all instrumentation from the > > > function, and any shadow writes will be lost. Even though this is > > > not a > > > concern with the current init_object() implementation, this may > > > change > > > in the future. > > > > > > Second, kmsan_poison_memory() calls may be added after memset() > > > calls. > > > The downside is that init_object() is called from > > > free_debug_processing(), in which case poisoning will erase the > > > distinction between simply uninitialized memory and UAF. > > > > > > Signed-off-by: Ilya Leoshkevich > > > --- > > > mm/kmsan/hooks.c | 2 +- > > > mm/slub.c | 13 +++++++++---- > > > 2 files changed, 10 insertions(+), 5 deletions(-) > > > > > [...] > > > --- a/mm/slub.c > > > +++ b/mm/slub.c > > > @@ -1139,7 +1139,12 @@ static void init_object(struct kmem_cache > > > *s, void *object, u8 val) > > > unsigned int poison_size =3D s->object_size; > > > > > > if (s->flags & SLAB_RED_ZONE) { > > > - memset(p - s->red_left_pad, val, s->red_left_pad); > > > + /* > > > + * Use __memset() here and below in order to avoid > > > overwriting > > > + * the KMSAN shadow. Keeping the shadow makes it > > > possible to > > > + * distinguish uninit-value from use-after-free. > > > + */ > > > + __memset(p - s->red_left_pad, val, s- > > > >red_left_pad); > > > > I found my build test[1] fails with below error on latest mm-unstable > > branch. > > 'git bisect' points me this patch. > > > > CC mm/slub.o > > /mm/slub.c: In function 'init_object': > > /mm/slub.c:1147:17: error: implicit declaration of function > > '__memset'; did you mean 'memset'? [-Werror=3Dimplicit-function- > > declaration] > > 1147 | __memset(p - s->red_left_pad, val, s- > > >red_left_pad); > > | ^~~~~~~~ > > | memset > > cc1: some warnings being treated as errors > > > > I haven't looked in deep, but reporting first. Do you have any idea? > > > > [1] > > https://github.com/awslabs/damon-tests/blob/next/corr/tests/build_m68k.= sh > > > > > > Thanks, > > SJ > > > > [...] > > Thanks for the report. > > Apparently not all architectures have __memset(). We should probably go > back to memset_no_sanitize_memory() [1], but this time mark it with > noinline __maybe_unused __no_sanitize_memory, like it's done in, e.g., > 32/35. > > Alexander, what do you think? We could probably go without __no_sanitize_memory assuming that platforms supporting KMSAN always have __memset(): #if defined(CONFIG_KMSAN) static inline void *memset_no_sanitize_memory(void *s, int c, size_t n) { return __memset(s, c, n); } #else static inline void *memset_no_sanitize_memory(void *s, int c, size_t n) { return memset(s, c, n); } #endif