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 64260C636D7 for ; Fri, 10 Feb 2023 20:07:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233561AbjBJUHx (ORCPT ); Fri, 10 Feb 2023 15:07:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44854 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233556AbjBJUHw (ORCPT ); Fri, 10 Feb 2023 15:07:52 -0500 Received: from mail-yw1-x112d.google.com (mail-yw1-x112d.google.com [IPv6:2607:f8b0:4864:20::112d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3EAF675340 for ; Fri, 10 Feb 2023 12:07:51 -0800 (PST) Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-520dad0a7d2so82859587b3.5 for ; Fri, 10 Feb 2023 12:07:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=541R7X11Cy7AiuNbaDBckfxjLzUeKrAJruA5EVPMTQQ=; b=hOWYki28ryvOUXUZ/hFXOJd1WEjvUxxka8fJZVK7Vqhg1G8crj5f6xChzdLCRRxiNa I+qq35Q2lsK21Tl8k2XxE+r8x0HwlzSsRPRlZilCR6JTdwUa9cQgxYS9DBKYzzD9bb4T naCKm3F0c4XfJJrSHmgDqDHyCpSKFcIKNs1J5/EXT3MMFkBe/U4MJAtKhAbRUOvTCswi SLwcCr3q8OSSHKCKPWhjnLBdpVv5a9J7bgZvespitNTL+K5QpE1dsyEbn1gmnAi1zVaY VziPrLiVc7y/ZlNw0jz5fh1SmMyY//jKD6wXr6VMB+WKRbBg1GKuz9jQFAbVrGJ+1TC+ MfyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=541R7X11Cy7AiuNbaDBckfxjLzUeKrAJruA5EVPMTQQ=; b=bzU5CO3vaZ0P8HsJLEKXywuamcCFGojKKKbo9gICImeqkaU81GDEKbGEt7+buITvEr vTpAqh6Hf+LO4xpGDclZ12nyuS4zSI7DcLAhRr6AdQibSxCeP9w4r4S6nZM0UcxpDhHC 5CWdn2nb4anbak405bfNwSvJZ1zJhi3vyRy43PcXRcn+xFeaopSdhZ3Ql365kRZST261 3KGz6klyEyGqhabe+u6uVxsp2V27PhIpq5Uod/DJ+zhZKPftmU/Ni7XWfTeBxJHKJRf4 IuuZU2pRbcCN4LGA2sEIuIqIh76raDEMazmopfUJ71vDI2LmfQ8CZxk0o2XL65M/48DC JrEA== X-Gm-Message-State: AO0yUKWNgreZeH+UcFilEZOidMaew3PAbg2JhyEV3X0n6ihJtjBvZmDT JtnAUbR+DeRZuF5VdYst4COGkMlElu2E6TazdQCBPg== X-Google-Smtp-Source: AK7set8iV8xt2HSvCwQI95K8KwUzewzFYe+DleZq6DnhxlKs9eaGXKm7jTifQcV/qN+YliFhvwT6LgHRli/KJKorl6k= X-Received: by 2002:a81:7dc6:0:b0:52a:1bac:b96d with SMTP id y189-20020a817dc6000000b0052a1bacb96dmr1660623ywc.349.1676059670297; Fri, 10 Feb 2023 12:07:50 -0800 (PST) MIME-Version: 1.0 References: <20230208184203.2260394-1-elver@google.com> In-Reply-To: From: Marco Elver Date: Fri, 10 Feb 2023 21:07:14 +0100 Message-ID: Subject: Re: [PATCH -tip] kasan: Emit different calls for instrumentable memintrinsics To: Jakub Jelinek Cc: Peter Zijlstra , Masahiro Yamada , Nathan Chancellor , Nick Desaulniers , Nicolas Schier , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , linux-kbuild@vger.kernel.org, kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, Ingo Molnar , Tony Lindgren , Ulf Hansson , linux-toolchains@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Fri, 10 Feb 2023 at 20:25, Jakub Jelinek wrote: > > On Wed, Feb 08, 2023 at 07:42:03PM +0100, Marco Elver wrote: > > Clang 15 will provide an option to prefix calls to memcpy/memset/memmove > > with __asan_ in instrumented functions: https://reviews.llvm.org/D122724 > > > > GCC does not yet have similar support. > > GCC has support to rename memcpy/memset etc. for years, say on > following compiled with > -fsanitize=kernel-address -O2 -mstringop-strategy=libcall > (the last option just to make sure the compiler doesn't prefer to emit > rep mov*/stos* or loop or something similar, of course kernel can keep > whatever it uses) you'll get just __asan_memcpy/__asan_memset calls, > no memcpy/memset, while without -fsanitize=kernel-address you get > normally memcpy/memset. > Or do you need the __asan_* functions only in asan instrumented functions > and normal ones in non-instrumented functions in the same TU? Yes, exactly that: __asan_ in instrumented, and normal ones in no_sanitize functions; they can be mixed in the same TU. We can't rename normal mem*() functions everywhere. In no_sanitize functions (in particular noinstr), normal mem*() should be used. But in instrumented code, it should be __asan_mem*(). Another longer explanation I also just replied here: https://lore.kernel.org/all/CANpmjNNH-O+38U6zRWJUCU-eJTfMhUosy==GWEOn1vcu=J2dcw@mail.gmail.com/ At least clang has had this behaviour for user space ASan forever: https://godbolt.org/z/h5sWExzef - so it was easy to just add the flag to make it behave like in user space for mem*() in the kernel. It might also be worthwhile for GCC to emit __asan_ for user space, given that the runtimes are shared and the user space runtime definitely has __asan_. The kernel needs the param (asan-kernel-mem-intrinsic-prefix) though, to not break older kernels. Thanks, -- Marco