Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp2411771rdb; Fri, 8 Dec 2023 07:26:34 -0800 (PST) X-Google-Smtp-Source: AGHT+IEsQpJGS2bdQiuHA1JHWnzbJ9Mf29k3Vl3pC2DLrs0883JGRrjVarNxE/CHLe0J0AThi1kC X-Received: by 2002:a17:902:da84:b0:1d0:6ffd:8345 with SMTP id j4-20020a170902da8400b001d06ffd8345mr173144plx.80.1702049194544; Fri, 08 Dec 2023 07:26:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702049194; cv=none; d=google.com; s=arc-20160816; b=YgjSxjyzD6rHTFEXBfcsZKjxKjov7YcINUfQuILC3kVPOAQZagR8d6A7ncqy0fQyXW 3FSJHfrJVfSotPRvxub1APszUycapuWfQliXMcxZISlhA4pV7g0k3BlE9RIJ7rY28gJd vYPAMFppzDqEPWwlaEk8ODceIGpzmaaMHrLGmJMdd37xJSxpt9nUtgYp3fseeY2Vh+Fm VKnM/QfGnQiuqD5kNf0BZ0eJI5UVKneFFULtiHRjQgkH9ULPxs/+p6sCE/ci+O3KmCIT 8T6cVxp/lxSKa+98imNwZonxIDyZ7W5F+gwxexyImkkHy4q9QI5uowAbzKrpqwpbiRnq mTvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=fmveRht4WTP9VCfRGY2TlBDNiNt4nqiRyGovDc1Drhw=; fh=kmKVJfn1Y9YZhlVPpqCDHuVVZsVgm/oqvGOUm8JK+fE=; b=b+S1lA9xVOWYZvUzQFzhXXKxt6HGXAjBeqOQ5hvcnMsk6YFBX52ynlEtgezFTaiK5a fWZLR63j909SXANqbWrFdvxx3fKxZ6qBH/4VGS909b8bSXVtFXPDojdnhYMV6DPKfZuP wKqj8L2m0LK7yZbUsDxKmZlCWf5+Oz++JWTpohgwUW0eZQ5xIWA6nUVWNUceJTOPlzzg OIa0D+9fLAngGyWfrmre2VqMx7BUnMouEt+9hzThA2zQXYlPrJGMZRAXAdpQjlr7/dp0 cTSx0aSJ/i1cIVioXDdkVDbYuqKhgYyW0MdX1t7jidP08cZRb1juDhr4suiRtnnKoRnQ Me4g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=aMIRCreY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from morse.vger.email (morse.vger.email. [2620:137:e000::3:1]) by mx.google.com with ESMTPS id z5-20020a170902834500b001c9c967e77esi1707138pln.207.2023.12.08.07.26.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Dec 2023 07:26:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=aMIRCreY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id BBF298379A7B; Fri, 8 Dec 2023 07:26:31 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233504AbjLHP0S (ORCPT + 99 others); Fri, 8 Dec 2023 10:26:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60810 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232481AbjLHP0R (ORCPT ); Fri, 8 Dec 2023 10:26:17 -0500 Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 277E710C0 for ; Fri, 8 Dec 2023 07:26:23 -0800 (PST) Received: by mail-qv1-xf30.google.com with SMTP id 6a1803df08f44-67a91a373edso12402316d6.1 for ; Fri, 08 Dec 2023 07:26:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1702049182; x=1702653982; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fmveRht4WTP9VCfRGY2TlBDNiNt4nqiRyGovDc1Drhw=; b=aMIRCreY4ebtSeY0kuQfq/myxA8NG1/q9ulVo+sy+stLhCK+0g21pM/oW+mXxiyaPH euIZ89cc/WUx5YyxRBoawfCZ860qQ08RYlBZytEYMUudTBY4FNW2/Ju3JUc3/8LybZFX PrBUC3ee9CwFbQ78QNKWmeVcA0rt8APAt26Y7oj+IypxMD5yPtAp5+FIQyfCX8Fh2oLq f39dD6e1sDbB0g9oaz7QP2jI4f9k6bxEZ8qKLDMRO02qzGJwzlDVTkKvzZoHIFPIKP7m mqgl3JrQJ35e3zR9peAkFumSVix0iZepCWZAgcTzrj6zm41jv6cQAZbJVUs6Ct9DhbpY JtEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702049182; x=1702653982; h=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=fmveRht4WTP9VCfRGY2TlBDNiNt4nqiRyGovDc1Drhw=; b=jPaTjK/95KVAX12vanIgApLRGf0Gh4hxgSJwE+2JJAVVlR70yDWHYDmlJDyvPtAOFD rqfU2T6sUdmk2w1HTBQcf6FuuGSEddAwPG4vVSRmVV2at9wcJTXGNQXtyU2V52qSJkY0 vhI4AakWjT+yf7w750Ihj/YIvg/TX0aqXrrX4Duyrk+vMVa2mx3naIzyx3+t/w1v+4V7 +f4Dskllepd87kWN4UEp1GNCl3WyUzQIJalohoFp7wAjo1pz+F5k6TvRF4V2K0i4OrC5 6qPrBUnlLTFCQ0uBcjfo3B1fM0P2cSe8fJhFI4GjkV6P4ALSz+dkcELpwtZ//pODVNx/ pFGA== X-Gm-Message-State: AOJu0YxshTy6d/gf82G7Tex9BvKTV0acvzt8OlPXytoN7zEbQ9dondnG t9sUwUOqQUILHLm+/4dRowU2j7OU8IUCIYk5WlHSQQ== X-Received: by 2002:ad4:52eb:0:b0:67a:a721:82f8 with SMTP id p11-20020ad452eb000000b0067aa72182f8mr105489qvu.82.1702049182002; Fri, 08 Dec 2023 07:26:22 -0800 (PST) MIME-Version: 1.0 References: <20231121220155.1217090-1-iii@linux.ibm.com> <20231121220155.1217090-14-iii@linux.ibm.com> <69e7bc8e8c8a38c429a793e991e0509cb97a53e1.camel@linux.ibm.com> In-Reply-To: <69e7bc8e8c8a38c429a793e991e0509cb97a53e1.camel@linux.ibm.com> From: Alexander Potapenko Date: Fri, 8 Dec 2023 16:25:41 +0100 Message-ID: Subject: Re: [PATCH v2 13/33] kmsan: Introduce memset_no_sanitize_memory() 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" X-Spam-Status: No, score=-8.4 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Fri, 08 Dec 2023 07:26:31 -0800 (PST) > A problem with __memset() is that, at least for me, it always ends > up being a call. There is a use case where we need to write only 1 > byte, so I thought that introducing a call there (when compiling > without KMSAN) would be unacceptable. Wonder what happens with that use case if we e.g. build with fortify-source. Calling memset() for a single byte might be indicating the code is not hot. > > ... > > > > > +__no_sanitize_memory > > > +static inline void *memset_no_sanitize_memory(void *s, int c, > > > size_t n) > > > +{ > > > + return memset(s, c, n); > > > +} > > > > I think depending on the compiler optimizations this might end up > > being a call to normal memset, that would still change the shadow > > bytes. > > Interesting, do you have some specific scenario in mind? I vaguely > remember that in the past there were cases when sanitizer annotations > were lost after inlining, but I thought they were sorted out? Sanitizer annotations are indeed lost after inlining, and we cannot do much about that. They are implemented using function attributes, and if a function dissolves after inlining, we cannot possibly know which instructions belonged to it. Consider the following example (also available at https://godbolt.org/z/5r7817G8e): ================================== void *kmalloc(int size); __attribute__((no_sanitize("kernel-memory"))) __attribute__((always_inline)) static void *memset_nosanitize(void *s, int c, int n) { return __builtin_memset(s, c, n); } void *do_something_nosanitize(int size) { void *ptr = kmalloc(size); memset_nosanitize(ptr, 0, size); return ptr; } void *do_something_sanitize(int size) { void *ptr = kmalloc(size); __builtin_memset(ptr, 0, size); return ptr; } ================================== If memset_nosanitize() has __attribute__((always_inline)), the compiler generates the same LLVM IR calling __msan_memset() for both do_something_nosanitize() and do_something_sanitize(). If we comment out this attribute, do_something_nosanitize() calls memset_nosanitize(), which doesn't have the sanitize_memory attribute. But even now __builtin_memset() is still calling __msan_memset(), because __attribute__((no_sanitize("kernel-memory"))) somewhat counterintuitively still preserves some instrumentation (see include/linux/compiler-clang.h for details). Replacing __attribute__((no_sanitize("kernel-memory"))) with __attribute__((disable_sanitizer_instrumentation)) fixes this situation: define internal fastcc noundef ptr @memset_nosanitize(void*, int, int)(ptr noundef returned writeonly %s, i32 noundef %n) unnamed_addr #2 { entry: %conv = sext i32 %n to i64 tail call void @llvm.memset.p0.i64(ptr align 1 %s, i8 0, i64 %conv, i1 false) ret ptr %s } > > And, in any case, if this were to happen, would not it be considered a > compiler bug that needs fixing there, and not in the kernel? As stated above, I don't think this is more or less working as intended. If we really want the ability to inline __memset(), we could transform it into memset() in non-sanitizer builds, but perhaps having a call is also acceptable?