Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp865819rwl; Thu, 5 Jan 2023 05:47:55 -0800 (PST) X-Google-Smtp-Source: AMrXdXvQhZ22msUQuTtRPvhpE2/VcubvJSFhi8w+MjeAPrqh6RhW3yZRdEBJ3zSjAJbUnW6O6NfB X-Received: by 2002:a17:903:20d3:b0:192:f4b0:a9ef with SMTP id i19-20020a17090320d300b00192f4b0a9efmr4715042plb.32.1672926475427; Thu, 05 Jan 2023 05:47:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672926475; cv=none; d=google.com; s=arc-20160816; b=SvqrNkMin4xaVUdHguARPylJ6YL+bLPPg5/OtOepfQGZ7A3t8XuE2V9KtgGdGv9KBR OSXTW3o+WaY5YwStdi4TXQht4YywH/gKDPVIaL+zDhN5ZCeZ16nUmrN/EPVXtI4rvIju 80f7c3OQeFl+KL0gO5yHUk/JnpLr1BX8bnkY9E+bbgn3QWchh8nm2BC6Lftcyx2V16yB oMxzWOnyPgjsfO8MguRDVoFCkBOEUAQKj62pdtHodj3UtGMWhNeCchU/rZnEfJGJ3hsc 7HI1E4n/jxBwgbIJP4HN6xeZeYh8u5Le9xnEJzYckJC4MMhW0YY2+PCyC07bt0fK+TWx JXJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:to:content-language:subject:user-agent:mime-version:date :message-id; bh=VIbQI53cWjz9kyM9t24jRkeRoQ0B76yI/QbCLokfVcY=; b=vGAujVWtjWaPCuPy0GrLpSkGYF7buOawHi9j+i/vTioObRbnIOfnFbUrJZC8RdO4K2 VHTZ3eKEfkNUd0f9N1vxySEiQXgJ+uTXpBh52D9+ZV+vbmFANAiE1xae6wtFbk1UsiNM aT+k9MfbIFTuopVdUv25O/nL3ekeTeNilMOnE43q3OS56+8pF5MTITdHRTZd8WOfoBEA r5zHcPiIYgn6wH7lJvEu6g7AjsEemdrOExRKsB+MN4yAf/w8cYrqh9GTZ6fHZZUatUPZ VYnsW8E0bmjnSvjhoQk8tj7pxJNwAO+vPFJ913JecNpLb0vKOjzPCR9pkUSGhIo58nfY Xq2Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f129-20020a636a87000000b004781187bdd0si37065002pgc.397.2023.01.05.05.47.47; Thu, 05 Jan 2023 05:47:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233839AbjAENSc (ORCPT + 56 others); Thu, 5 Jan 2023 08:18:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37122 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231964AbjAENRr (ORCPT ); Thu, 5 Jan 2023 08:17:47 -0500 Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C51442003 for ; Thu, 5 Jan 2023 05:17:46 -0800 (PST) Received: from fsav313.sakura.ne.jp (fsav313.sakura.ne.jp [153.120.85.144]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 305DHOub054514; Thu, 5 Jan 2023 22:17:24 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav313.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav313.sakura.ne.jp); Thu, 05 Jan 2023 22:17:24 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav313.sakura.ne.jp) Received: from [192.168.1.20] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 305DHOkc054511 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Jan 2023 22:17:24 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: <032386fc-fffb-1f17-8cfd-94b35b6947ee@I-love.SAKURA.ne.jp> Date: Thu, 5 Jan 2023 22:17:24 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH] fbcon: Use kzalloc() in fbcon_prepare_logo() Content-Language: en-US To: Alexander Potapenko , Geert Uytterhoeven , Marco Elver , Dmitry Vyukov , kasan-dev , Helge Deller , Linux Fbdev development list , DRI , Linux Kernel Mailing List , Kees Cook References: <86bdfea2-7125-2e54-c2c0-920f28ff80ce@I-love.SAKURA.ne.jp> From: Tetsuo Handa In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,NICE_REPLY_A, SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2023/01/05 20:54, Daniel Vetter wrote: >>> . Plain memset() in arch/x86/include/asm/string_64.h is redirected to __msan_memset() >>> but memsetXX() are not redirected to __msan_memsetXX(). That is, memory initialization >>> via memsetXX() results in KMSAN's shadow memory being not updated. >>> >>> KMSAN folks, how should we fix this problem? >>> Redirect assembly-implemented memset16(size) to memset(size*2) if KMSAN is enabled? >>> >> >> I think the easiest way to fix it would be disable memsetXX asm >> implementations by something like: >> >> ------------------------------------------------------------------------------------------------- >> diff --git a/arch/x86/include/asm/string_64.h b/arch/x86/include/asm/string_64.h >> index 888731ccf1f67..5fb330150a7d1 100644 >> --- a/arch/x86/include/asm/string_64.h >> +++ b/arch/x86/include/asm/string_64.h >> @@ -33,6 +33,7 @@ void *memset(void *s, int c, size_t n); >> #endif >> void *__memset(void *s, int c, size_t n); >> >> +#if !defined(__SANITIZE_MEMORY__) >> #define __HAVE_ARCH_MEMSET16 >> static inline void *memset16(uint16_t *s, uint16_t v, size_t n) >> { >> @@ -68,6 +69,7 @@ static inline void *memset64(uint64_t *s, uint64_t >> v, size_t n) >> : "memory"); >> return s; >> } >> +#endif > > So ... what should I do here? Can someone please send me a revert or patch > to apply. I don't think I should do this, since I already tossed my credit > for not looking at stuff carefully enough into the wind :-) > -Daniel > >> >> #define __HAVE_ARCH_MEMMOVE >> #if defined(__SANITIZE_MEMORY__) && defined(__NO_FORTIFY) >> ------------------------------------------------------------------------------------------------- >> >> This way we'll just pick the existing C implementations instead of >> reinventing them. >> I'd like to avoid touching per-arch asm/string.h files if possible. Can't we do like below (i.e. keep asm implementations as-is, but automatically redirect to __msan_memset()) ? If yes, we could move all __msan_*() redirection from per-arch asm/string.h files to the common linux/string.h file? diff --git a/include/linux/string.h b/include/linux/string.h index c062c581a98b..403813b04e00 100644 --- a/include/linux/string.h +++ b/include/linux/string.h @@ -360,4 +360,15 @@ static __always_inline size_t str_has_prefix(const char *str, const char *prefix return strncmp(str, prefix, len) == 0 ? len : 0; } +#if defined(__SANITIZE_MEMORY__) && defined(__NO_FORTIFY) +#undef memset +#define memset(dest, src, count) __msan_memset((dest), (src), (count)) +#undef memset16 +#define memset16(dest, src, count) __msan_memset((dest), (src), (count) << 1) +#undef memset32 +#define memset32(dest, src, count) __msan_memset((dest), (src), (count) << 2) +#undef memset64 +#define memset64(dest, src, count) __msan_memset((dest), (src), (count) << 3) +#endif + #endif /* _LINUX_STRING_H_ */