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 DFF7CC4167B for ; Fri, 8 Dec 2023 13:52:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7A20E6B0088; Fri, 8 Dec 2023 08:52:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 72A996B0089; Fri, 8 Dec 2023 08:52:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5CB536B008A; Fri, 8 Dec 2023 08:52:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 47A7E6B0088 for ; Fri, 8 Dec 2023 08:52:34 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 14AA3C0226 for ; Fri, 8 Dec 2023 13:52:34 +0000 (UTC) X-FDA: 81543791028.18.656E6A1 Received: from mail-qv1-f49.google.com (mail-qv1-f49.google.com [209.85.219.49]) by imf07.hostedemail.com (Postfix) with ESMTP id 2920D40021 for ; Fri, 8 Dec 2023 13:52:31 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=EhWNLx2i; spf=pass (imf07.hostedemail.com: domain of glider@google.com designates 209.85.219.49 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=1702043552; 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=kxr02EuEVtCzgI9ve8IFgXJLU7RV4njnkPo6roz6Un8=; b=0p7ZLQl9jR66OgzGs+o8C6SeVZ+/wjRWrOg7weP993yBaYm5iMp60a71kBdwjBy6FIJLzz 6N4Tr8wm97E1pm+2FKDtinqoZWTOc1OnUE9yxrDgJoo5HSs5lTLHDmeNcvtRuWCdbUcWur kvfxJ3FxoHevBWLSCpwHXaetY8a7IWk= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=EhWNLx2i; spf=pass (imf07.hostedemail.com: domain of glider@google.com designates 209.85.219.49 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702043552; a=rsa-sha256; cv=none; b=NFPADfTR44e31OhZ4QN1YndnSLooebKaf9M35gAzU3jm2ReCPTF74la8YhI052TGNM/PYv QkqXwNNbVcHEKopzerPOUYlpwXothGXZmkmftgwvpVZuo6gEjUHpwASkFSK57sLoaOMKpj O7vpfkrFV3WrDhbnIRMMefyiRi8yauo= Received: by mail-qv1-f49.google.com with SMTP id 6a1803df08f44-67ad032559fso11460216d6.2 for ; Fri, 08 Dec 2023 05:52:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1702043551; x=1702648351; 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=kxr02EuEVtCzgI9ve8IFgXJLU7RV4njnkPo6roz6Un8=; b=EhWNLx2irfvHskKXRLxlM3HSMK0BDSxlouKPlZ3FTHg76SPS5MaiiAYV34kOzuPm/e QdUJUyMzcoYXUTT32kS4RmRbLuLZ3EJ6/PrFTG1O5BCkURXzzMd/nvU/ZrdXcnjgwgRx gnVAUMrgWFbic67Xt080bpDbAIRrfcBx/gxXjnmoAAhLRvPYEwGK2mreR2f6IveUJONq VQfYa0chs0drz/2Is3UUtH1nsxCe+y6LUXT5zwcQuy+cbO39uT/1a4R9Rt+ca0DHXT5l Eo2KoHPNbsXCU97LG9On8l8Q1dJ4XSzvuBoCvCvH1Qm9gJBGTiL+DHcALbPq9BuLoCZu MCiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702043551; x=1702648351; 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=kxr02EuEVtCzgI9ve8IFgXJLU7RV4njnkPo6roz6Un8=; b=mA+CnK2lQWCnx13R5Fp9MSBuN1HD/ZjegoN51YR2YQ0eKNrdr3DRVTBC7puDSozvjA TBLI8YfNrWFZag6l3xay+R2pZ51BlCAcVHrncbfAA+NfabvqFEInbT80qMvrxZPJALEq aQ1wP6TEb3g9/b17IluuvFshE8HnuI6E6qOknfPICHZaa0ixdF2HTlbNSazZeEe3yn4f Sakcm3e2HQTLk2KfDZALxN7kf39mX5ltiJL+G6Q4RdVLOYX9TzqwwBJHYWfBQ3DCOI5t DNSdobQIWg8baP+hNisb3RegNDptCsDXXbXmw0h8SVI1qN0WK3N/D6POkpRcaDu2q4z+ Oj7A== X-Gm-Message-State: AOJu0YxONz3T3Sfy1Yw8oBse9m8RHfmFtjkr2pciSFYf4vvRfgIuljrB OEDH9OJ9nWGWayo5xMlTlJfkWYwKnpu1xp0Nf7dLPg== X-Google-Smtp-Source: AGHT+IE6sRnpL+taCI8PmNwlcDfKw8+NbZCU4p6sDWRNgt5aul5bA5OudQ9MrHnc4a/zgth0bHWfV2d1K6PDTg15VRA= X-Received: by 2002:ad4:50c8:0:b0:67a:d049:bd31 with SMTP id e8-20020ad450c8000000b0067ad049bd31mr4464764qvq.72.1702043551094; Fri, 08 Dec 2023 05:52:31 -0800 (PST) MIME-Version: 1.0 References: <20231121220155.1217090-1-iii@linux.ibm.com> <20231121220155.1217090-15-iii@linux.ibm.com> In-Reply-To: <20231121220155.1217090-15-iii@linux.ibm.com> From: Alexander Potapenko Date: Fri, 8 Dec 2023 14:51:51 +0100 Message-ID: Subject: Re: [PATCH v2 14/33] kmsan: Support SLAB_POISON To: Ilya Leoshkevich Cc: 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-Rspamd-Queue-Id: 2920D40021 X-Rspam-User: X-Stat-Signature: noh41jk4y953fhbnjp57q6988u8d63si X-Rspamd-Server: rspam01 X-HE-Tag: 1702043551-222196 X-HE-Meta: U2FsdGVkX1/z1rejfSEbvB9PVed0sRPaKJVfcyAgEw80I9urpVywsI+vNwBoKIKKHPSxR5eZwGKe2kUxj3LPQBN6p+AG4OxMDspvwUOZW2t5CTWVeUaVeZLxm4fSqwIum3+uSBN2kXNn6QkQOzjejpAC7rE6FM10oTKONa4gRhE++eQQLmx8CPLryi6wgDXgVA+TJIE1ckcZW+Mk+64LmCm4AH/YMHD5uUzUqNgDyuyV8wLJ5NvTxJDoYlWfLqPivM8OwDyqDH027dolu7le5StoI0BztwJAuPdcLbOd6GWrbJ7gUHs5AWG8Sx0VHY2osmrHmmt3D/hojizA2b9jCf4CHxIRrIRC+MguXFBxks05p02UecuORxLvqQmkJQyJboDkdnigSEvPBBYuC4bqH2pJKiFps+uC+SNe/WjOCQFVilLmGbexcePwwnr+ldgChp5kb4g0zlSRZlMOKaQbWYQ4RxDidlJ+WIl01wPHwyKQNgisDmI0z1CHL1N5HIN2LPIaI0pGkVdHQrIZm7200dqD6MYheldo2FfwCTXBXd22ZXTcJERF15p0MWUlALVD0dFRfTrSx+mCPLEg9GvNrJfYQlVa2UX7NATh1HsYh9sXmIlK6H9QHdCMMvzRVih6TVZ7Fe5E+vOheRt1NysOz9YCRx+DAolufbY56yrh+GpptdEba0tjbKTLQH+u4aaX8ZxU6q869FddYH+9bTeGsqvPl93NC3I/OGZva45U0eECv6ZGrg56vJ3pFQ4DTBoLSC4UvWjWGNszNuEWaemeeTX/zIwP04st2J1bpZGajRq//cYqYJBnx9RoksYsO68JE6yiUdCT40iSguTrtaPJlAhc8HpiK483A0Rap9LuoUJmHYmWDFdj9hCcc5fBO3CJh9ZIRXDsVWO8JGYKKTYFvxiQ0bwXD1BXq+BlqlXdyvhHmvLF/OR6fGPaVilFVRF//qxOzxStZ15zmT0uDYH krcb+16R 4WIrxukIhoFajjrBnuLDtktBupKqCTGFQ7H6Y+Fgw67UD2e7jUcweP0gid2BPc0Zq2lKTOxo5DvYoWtaEUEUQnuR2Kdm6grhKYgwizbEO1wzsv5daeaMV0WPkPlx/yyGi2moYOpMgtBhYqZBMe4tbnc5iV1BEMJ9a4eqs6wECqIoZUXXbXvmuvWknNE2Bp/FqMIzo0oPcOnsPvKGjCm0jXJPa2SAqUj2qzvlkwMNivb8Rn+u9SAk85rtQGBMMtiZUlIrwgllF+2w4wuQF2NVQUdsjgVGONTAMccUHt6MWZL5mDJzEF6mzAV+BVMOFHVm8J/O0Ipd+rHy4/tBbbw9rPCGCtszaq7iHvuhn7OKHv9d3f+g= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000172, 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 Tue, Nov 21, 2023 at 11:02=E2=80=AFPM 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. The usage of > memset_no_sanitize_memory() does not degrade the generated code > quality. > > 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 | 10 ++++++---- > 2 files changed, 7 insertions(+), 5 deletions(-) > > diff --git a/mm/kmsan/hooks.c b/mm/kmsan/hooks.c > index 7b5814412e9f..7a30274b893c 100644 > --- a/mm/kmsan/hooks.c > +++ b/mm/kmsan/hooks.c > @@ -76,7 +76,7 @@ void kmsan_slab_free(struct kmem_cache *s, void *object= ) > return; > > /* RCU slabs could be legally used after free within the RCU peri= od */ > - if (unlikely(s->flags & (SLAB_TYPESAFE_BY_RCU | SLAB_POISON))) > + if (unlikely(s->flags & SLAB_TYPESAFE_BY_RCU)) > return; > /* > * If there's a constructor, freed memory must remain in the same= state > diff --git a/mm/slub.c b/mm/slub.c > index 63d281dfacdb..169e5f645ea8 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -1030,7 +1030,8 @@ 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); > + memset_no_sanitize_memory(p - s->red_left_pad, val, As I wrote in patch 13/33, let's try to use __memset() here (with a comment that we want to preserve the previously poisoned memory)