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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5A1FAC6FD18 for ; Tue, 18 Apr 2023 12:14:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231153AbjDRMNx (ORCPT ); Tue, 18 Apr 2023 08:13:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48972 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231698AbjDRMNk (ORCPT ); Tue, 18 Apr 2023 08:13:40 -0400 Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1B42776BE for ; Tue, 18 Apr 2023 05:13:17 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id ca18e2360f4ac-7606d443bb2so90795339f.1 for ; Tue, 18 Apr 2023 05:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1681819996; x=1684411996; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3C41xG4p1BHPpadBDL6pJd1psfwz5yd3WchMAQj7wTI=; b=Jyi6R/m83VokG9frSymybQC2AFMBTwvKU6IH5SFWbNjoMUuihDbL0fvrWRHM6fEqgd I2k47/ZF5tI1vrJWYWIykz1ylPVltQkexdvlSPDZYCgJnZzCaMTDv7BxcRoGrWxVeAzB HDEKS/SmuA/bzYbFywmTHTLYu8W2uNraQzCUNzjqcdhps8XlbmuhEWVF3zrVq5oHHMaC +SI/TmqjkiRknqu/hej1YElkV7TId33p5MBVP/dLCVBDfuW/ppoMS6k9YE+/lVByu+gu S+ge3LbP56WzvGvqntgCTFsEfFQPT0BnuVAhHl3ukFLSOdNN02OFZZkKWZ+k5KMAcq6r rDrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681819996; x=1684411996; 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=3C41xG4p1BHPpadBDL6pJd1psfwz5yd3WchMAQj7wTI=; b=PDhhAZeivIb0ey5AykxZ95+iE+ZOaDUFDzOhxPY1Hr15FA3SW7vyhtnLJKKH6huj1j HP8yVVnsb4BV6h5DZ2s9a2tpraFYjrgV5UlPW2/hpgzmbJWDYqXZ8Zhw/cWPllFzoUjW 9R1TKMp98xT9RAIQpCh6cX39RS5/UOcoHOTyLWy3pVtXIEvRoVxTbRoA3wZvFNHyz3IH +Jps4tzoUss1X7bVVUHas0J1ycWpl275VOHXzT6zYoOB/xsEmEBdQQjcgNJn2atgISvs ecGt05qlth8e5Lpm1pY7eLmTRmgM0HpaE9+wxitfLrwvQEJl+R0dX+IbkBpQbLNciNK0 GliQ== X-Gm-Message-State: AAQBX9e/GtjBxyrridmoKbDnq8Ppr0u+nlq102gsaODcvh0u4FNk4dwg WMGVsXTWbqpgAwjn+opVFUKfxDBM75cRqh9wdSBWvw== X-Google-Smtp-Source: AKy350ZfZvWa02fGm9TNYBrnOE+KkUawW1Q+TjXvWWE0Le8UwLNHTJEKGZCr3PzZ4WA37tJhHE1QeuNMJWiiACAZIic= X-Received: by 2002:a6b:6e06:0:b0:762:7e58:8d38 with SMTP id d6-20020a6b6e06000000b007627e588d38mr1759080ioh.10.1681819995595; Tue, 18 Apr 2023 05:13:15 -0700 (PDT) MIME-Version: 1.0 References: <20230224085942.1791837-1-elver@google.com> In-Reply-To: From: Marco Elver Date: Tue, 18 Apr 2023 14:12:39 +0200 Message-ID: Subject: Re: [PATCH v5 1/4] kasan: Emit different calls for instrumentable memintrinsics To: Catalin Marinas Cc: Andrew Morton , Peter Zijlstra , Jakub Jelinek , linux-toolchains@vger.kernel.org, Alexander Potapenko , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Andrey Ryabinin , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Nathan Chancellor , Nick Desaulniers , Nicolas Schier , Kees Cook , linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kbuild@vger.kernel.org, linux-hardening@vger.kernel.org, Linux Kernel Functional Testing , Naresh Kamboju Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Thu, 13 Apr 2023 at 16:14, Catalin Marinas wrote: > > Hi Marco, > > On Fri, Feb 24, 2023 at 09:59:39AM +0100, Marco Elver wrote: > > Clang 15 provides an option to prefix memcpy/memset/memmove calls with > > __asan_/__hwasan_ in instrumented functions: https://reviews.llvm.org/D122724 > > > > GCC will add support in future: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108777 > > > > Use it to regain KASAN instrumentation of memcpy/memset/memmove on > > architectures that require noinstr to be really free from instrumented > > mem*() functions (all GENERIC_ENTRY architectures). > > > > Fixes: 69d4c0d32186 ("entry, kasan, x86: Disallow overriding mem*() functions") > > Signed-off-by: Marco Elver > > Acked-by: Peter Zijlstra (Intel) > > Reviewed-by: Andrey Konovalov > > Tested-by: Linux Kernel Functional Testing > > Tested-by: Naresh Kamboju > [...] > > diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan > > index b9e94c5e7097..fa9f836f8039 100644 > > --- a/scripts/Makefile.kasan > > +++ b/scripts/Makefile.kasan > > @@ -38,6 +38,11 @@ endif > > > > CFLAGS_KASAN += $(call cc-param,asan-stack=$(stack_enable)) > > > > +# Instrument memcpy/memset/memmove calls by using instrumented __asan_mem*() > > +# instead. With compilers that don't support this option, compiler-inserted > > +# memintrinsics won't be checked by KASAN on GENERIC_ENTRY architectures. > > +CFLAGS_KASAN += $(call cc-param,asan-kernel-mem-intrinsic-prefix=1) > > + > > endif # CONFIG_KASAN_GENERIC > > > > ifdef CONFIG_KASAN_SW_TAGS > > @@ -54,6 +59,9 @@ CFLAGS_KASAN := -fsanitize=kernel-hwaddress \ > > $(call cc-param,hwasan-inline-all-checks=0) \ > > $(instrumentation_flags) > > > > +# Instrument memcpy/memset/memmove calls by using instrumented __hwasan_mem*(). > > +CFLAGS_KASAN += $(call cc-param,hwasan-kernel-mem-intrinsic-prefix=1) > > This patch breaks the arm64 kernel builds with KASAN_SW_TAGS enabled and > clang prior to version 15. Those prior clang versions don't like the > '-mllvm -hwasan-kernel-mem-intrinsic-prefix=1' option, end up printing > the help text instead of generating the object. > > Do we need some combination of cc-option and cc-param? Or at least > disable this instrumentation if earlier clang versions are used. > > It's already in mainline as commit > 51287dcb00cc715c27bf6a6b4dbd431621c5b65a. Arnd posted a patch, but the reason why a workaround is needed is quite unfortunate: https://lore.kernel.org/all/CANpmjNMwYosrvqh4ogDO8rgn+SeDHM2b-shD21wTypm_6MMe=g@mail.gmail.com/ Clang apparently interprets unknown options that start with "-h..", i.e. "-mllvm -h..." as a request to print help text, which has exit code 0. So this is only a problem for hwasan options.