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 40F9EC433F5 for ; Fri, 18 Mar 2022 14:02:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A93588D0002; Fri, 18 Mar 2022 10:02:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A42028D0001; Fri, 18 Mar 2022 10:02:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8E4548D0002; Fri, 18 Mar 2022 10:02:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 7EB898D0001 for ; Fri, 18 Mar 2022 10:02:30 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 3E2EF2543B for ; Fri, 18 Mar 2022 14:02:30 +0000 (UTC) X-FDA: 79257672060.06.5D240E3 Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) by imf14.hostedemail.com (Postfix) with ESMTP id 6D807100016 for ; Fri, 18 Mar 2022 14:02:29 +0000 (UTC) Received: by mail-qk1-f170.google.com with SMTP id i65so970388qkd.7 for ; Fri, 18 Mar 2022 07:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=czhzuU8FdBgoTMOkVAUn4UY5djtUuAplVMJZkpdqnk0=; b=cH3CntooMeohG8vR+waeu0z5ry6QR/vm9oxiLycfwmKZKM5k6fnG/6h4mhuMsIVt/e uYlLRtp0mf9lup17qyTNfxQ2n82c6fvpGmogDlUz/z323kZp8Wk49pj7NKBPI4cmsOIJ a6A3uqyrEb9bRrbl9UjC/2dKx7OCOihSe3Io/ke36qN9Tdd2lwmF7jVfWVrtTI1mgEc3 d4SHIXLaCcYM7d6d1DRGA3FITjkdbZi21wvwZuDsmkBY+SjPavtd6inYANLzO84v/OSd R/TQoOjo5xvlfiBpfF5dP2aZZ9QEV7RfZS17tfpPUYDSnQCaxra/6taYk4gvfJJRJQJ1 VTxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=czhzuU8FdBgoTMOkVAUn4UY5djtUuAplVMJZkpdqnk0=; b=ROF/8fyBQB4KapwJVoyHTxuG9Zz/snn9N29AHdqPac2KrStVuedOKIAzBAExp3Pq9m xco5fEFXBUGnZQFXoLqclJPSJCbt9aEPXvDNjcUmBFbjFQ3bFh0cZfWB1u0vIfRsQjoK Tez//ocTRPnG+zhsIruefz7XniudY+ltCuJjUX0X1H3y8/0oXW8cdFBI0qHi48CTsAKr Szqtpm1Qp/tqMhrKiiXIgX7Fi6twV+/PH9AQ/Go2rLduHAkO9oViw3vTUwBx4bWYkADx DTeNVUIsfEDROKUZAPSzPb0yLGF48HvvePVEhm5VuxzZks1Ci2/34VmlcoC6AV88pWng 3lig== X-Gm-Message-State: AOAM532Z5exjcOuicLO3E5wXBix3Jzzrau9NzP0Mwrf6mYgFktBp/bC9 ETPJSEIOy7ieujIUVYVYgVFAwDRWJKRxZot9kzVtoA== X-Google-Smtp-Source: ABdhPJzNqGwIM8AfbnGOJfSsTRAE6asdsfXW/BsesxeWqorkk/tltYckgq0SnJIXn09R4BlnUqfJ/1m45Lq7q+X8l18= X-Received: by 2002:a05:620a:2985:b0:67d:b9ac:90b2 with SMTP id r5-20020a05620a298500b0067db9ac90b2mr5985578qkp.436.1647612147873; Fri, 18 Mar 2022 07:02:27 -0700 (PDT) MIME-Version: 1.0 References: <20211214162050.660953-1-glider@google.com> <20211214162050.660953-10-glider@google.com> In-Reply-To: From: Alexander Potapenko Date: Fri, 18 Mar 2022 15:01:51 +0100 Message-ID: Subject: Re: [PATCH 09/43] kmsan: introduce __no_sanitize_memory and __no_kmsan_checks To: Mark Rutland Cc: Alexander Viro , Andrew Morton , Andrey Konovalov , Andy Lutomirski , Ard Biesheuvel , Arnd Bergmann , Borislav Petkov , Christoph Hellwig , Christoph Lameter , David Rientjes , Dmitry Vyukov , Eric Dumazet , Greg Kroah-Hartman , Herbert Xu , Ilya Leoshkevich , Ingo Molnar , Jens Axboe , Joonsoo Kim , Kees Cook , Marco Elver , Matthew Wilcox , "Michael S. Tsirkin" , Pekka Enberg , Peter Zijlstra , Petr Mladek , Steven Rostedt , Thomas Gleixner , Vasily Gorbik , Vegard Nossum , Vlastimil Babka , Linux Memory Management List , Linux-Arch , LKML Content-Type: multipart/alternative; boundary="000000000000cdaff705da7e98c9" X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 6D807100016 X-Stat-Signature: 7y5qncucu5nkz7h1cb5r4yg85ecujqd5 Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=cH3Cntoo; spf=pass (imf14.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 X-Rspam-User: X-HE-Tag: 1647612149-378788 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: --000000000000cdaff705da7e98c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 15, 2021 at 2:27 PM Mark Rutland wrote: > On Tue, Dec 14, 2021 at 05:20:16PM +0100, Alexander Potapenko wrote: > > __no_sanitize_memory is a function attribute that instructs KMSAN to > > skip a function during instrumentation. This is needed to e.g. implemen= t > > the noinstr functions. > > > > __no_kmsan_checks is a function attribute that makes KMSAN > > ignore the uninitialized values coming from the function's > > inputs, and initialize the function's outputs. > > > > Functions marked with this attribute can't be inlined into functions > > not marked with it, and vice versa. > > Just to check, I assume an unmarked __always_inline() function can be > inlined > into a marked function? Otherwise this is going to be really painful to > manage > for low-level helper functions. > Yes, as a matter of fact __always_inline prevails over the requirement of having the same attribute. I'll probably need to clarify this in the description. > > Thanks, > Mark. > > > > > __SANITIZE_MEMORY__ is a macro that's defined iff the file is > > instrumented with KMSAN. This is not the same as CONFIG_KMSAN, which is > > defined for every file. > > > > Signed-off-by: Alexander Potapenko > > --- > > Link: > https://linux-review.googlesource.com/id/I004ff0360c918d3cd8b18767ddd1381= c6d3281be > > --- > > include/linux/compiler-clang.h | 23 +++++++++++++++++++++++ > > include/linux/compiler-gcc.h | 6 ++++++ > > 2 files changed, 29 insertions(+) > > > > diff --git a/include/linux/compiler-clang.h > b/include/linux/compiler-clang.h > > index 3c4de9b6c6e3e..5f11a6f269e28 100644 > > --- a/include/linux/compiler-clang.h > > +++ b/include/linux/compiler-clang.h > > @@ -51,6 +51,29 @@ > > #define __no_sanitize_undefined > > #endif > > > > +#if __has_feature(memory_sanitizer) > > +#define __SANITIZE_MEMORY__ > > +/* > > + * Unlike other sanitizers, KMSAN still inserts code into functions > marked with > > + * no_sanitize("kernel-memory"). Using disable_sanitizer_instrumentati= on > > + * provides the behavior consistent with other __no_sanitize_ > attributes, > > + * guaranteeing that __no_sanitize_memory functions remain > uninstrumented. > > + */ > > +#define __no_sanitize_memory __disable_sanitizer_instrumentation > > + > > +/* > > + * The __no_kmsan_checks attribute ensures that a function does not > produce > > + * false positive reports by: > > + * - initializing all local variables and memory stores in this > function; > > + * - skipping all shadow checks; > > + * - passing initialized arguments to this function's callees. > > + */ > > +#define __no_kmsan_checks __attribute__((no_sanitize("kernel-memory"))= ) > > +#else > > +#define __no_sanitize_memory > > +#define __no_kmsan_checks > > +#endif > > + > > /* > > * Support for __has_feature(coverage_sanitizer) was added in Clang 13 > together > > * with no_sanitize("coverage"). Prior versions of Clang support > coverage > > diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.= h > > index ccbbd31b3aae5..f6e69387aad05 100644 > > --- a/include/linux/compiler-gcc.h > > +++ b/include/linux/compiler-gcc.h > > @@ -129,6 +129,12 @@ > > #define __SANITIZE_ADDRESS__ > > #endif > > > > +/* > > + * GCC does not support KMSAN. > > + */ > > +#define __no_sanitize_memory > > +#define __no_kmsan_checks > > + > > /* > > * Turn individual warnings and errors on and off locally, depending > > * on version. > > -- > > 2.34.1.173.g76aa8bc2d0-goog > > > --=20 Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Diese E-Mail ist vertraulich. Falls Sie diese f=C3=A4lschlicherweise erhalt= en haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, l=C3=B6schen Sie alle Kopien und Anh=C3=A4nge davon und lassen Sie mich bit= te wissen, dass die E-Mail an die falsche Person gesendet wurde. This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person. --000000000000cdaff705da7e98c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 15, 2021 at 2:27 PM Mark = Rutland <mark.= rutland@arm.com> wrote:
On Tue, Dec 14, 2021 at 05:20:16PM +0100, Alexander Potapenk= o wrote:
> __no_sanitize_memory is a function attribute that instructs KMSAN to > skip a function during instrumentation. This is needed to e.g. impleme= nt
> the noinstr functions.
>
> __no_kmsan_checks is a function attribute that makes KMSAN
> ignore the uninitialized values coming from the function's
> inputs, and initialize the function's outputs.
>
> Functions marked with this attribute can't be inlined into functio= ns
> not marked with it, and vice versa.

Just to check, I assume an unmarked __always_inline() function can be inlin= ed
into a marked function? Otherwise this is going to be really painful to man= age
for low-level helper functions.

Yes, as= a matter of fact __always_inline prevails over the requirement of having t= he same attribute.
I'll probably need to clarify this in the = description.

Thanks,
Mark.

>
> __SANITIZE_MEMORY__ is a macro that's defined iff the file is
> instrumented with KMSAN. This is not the same as CONFIG_KMSAN, which i= s
> defined for every file.
>
> Signed-off-by: Alexander Potapenko <glider@google.com>
> ---
> Link: https:/= /linux-review.googlesource.com/id/I004ff0360c918d3cd8b18767ddd1381c6d3281be=
> ---
>=C2=A0 include/linux/compiler-clang.h | 23 +++++++++++++++++++++++
>=C2=A0 include/linux/compiler-gcc.h=C2=A0 =C2=A0|=C2=A0 6 ++++++
>=C2=A0 2 files changed, 29 insertions(+)
>
> diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-c= lang.h
> index 3c4de9b6c6e3e..5f11a6f269e28 100644
> --- a/include/linux/compiler-clang.h
> +++ b/include/linux/compiler-clang.h
> @@ -51,6 +51,29 @@
>=C2=A0 #define __no_sanitize_undefined
>=C2=A0 #endif
>=C2=A0
> +#if __has_feature(memory_sanitizer)
> +#define __SANITIZE_MEMORY__
> +/*
> + * Unlike other sanitizers, KMSAN still inserts code into functions m= arked with
> + * no_sanitize("kernel-memory"). Using disable_sanitizer_in= strumentation
> + * provides the behavior consistent with other __no_sanitize_ attribu= tes,
> + * guaranteeing that __no_sanitize_memory functions remain uninstrume= nted.
> + */
> +#define __no_sanitize_memory __disable_sanitizer_instrumentation
> +
> +/*
> + * The __no_kmsan_checks attribute ensures that a function does not p= roduce
> + * false positive reports by:
> + *=C2=A0 - initializing all local variables and memory stores in this= function;
> + *=C2=A0 - skipping all shadow checks;
> + *=C2=A0 - passing initialized arguments to this function's calle= es.
> + */
> +#define __no_kmsan_checks __attribute__((no_sanitize("kernel-mem= ory")))
> +#else
> +#define __no_sanitize_memory
> +#define __no_kmsan_checks
> +#endif
> +
>=C2=A0 /*
>=C2=A0 =C2=A0* Support for __has_feature(coverage_sanitizer) was added = in Clang 13 together
>=C2=A0 =C2=A0* with no_sanitize("coverage"). Prior versions o= f Clang support coverage
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc= .h
> index ccbbd31b3aae5..f6e69387aad05 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -129,6 +129,12 @@
>=C2=A0 #define __SANITIZE_ADDRESS__
>=C2=A0 #endif
>=C2=A0
> +/*
> + * GCC does not support KMSAN.
> + */
> +#define __no_sanitize_memory
> +#define __no_kmsan_checks
> +
>=C2=A0 /*
>=C2=A0 =C2=A0* Turn individual warnings and errors on and off locally, = depending
>=C2=A0 =C2=A0* on version.
> --
> 2.34.1.173.g76aa8bc2d0-goog
>


--
Alexander Potapenko
Software Engineer

Google Ge= rmany GmbH
Erika-Mann-Stra=C3=9Fe, 33
80636 M=C3=BCnchen

Gesch= =C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian
Registergericht und = -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

Diese = E-Mail ist vertraulich. Falls Sie diese f=C3=A4lschlicherweise erhalten hab= en sollten, leiten Sie diese bitte nicht an jemand anderes weiter, l=C3=B6s= chen Sie alle Kopien und Anh=C3=A4nge davon und lassen Sie mich bitte wisse= n, dass die E-Mail an die falsche Person gesendet wurde.


This e-= mail is confidential. If you received this communication by mistake, please= don't forward it to anyone else, please erase all copies and attachmen= ts, and please let me know that it has gone to the wrong person.
--000000000000cdaff705da7e98c9--