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 4D83DC433EF for ; Wed, 30 Mar 2022 14:45:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347122AbiC3OrQ (ORCPT ); Wed, 30 Mar 2022 10:47:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33964 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347115AbiC3OrQ (ORCPT ); Wed, 30 Mar 2022 10:47:16 -0400 Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 289B1BC08 for ; Wed, 30 Mar 2022 07:45:30 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id u3so29675418wrg.3 for ; Wed, 30 Mar 2022 07:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=RmXuJD4qZhRM82pfRtozOF5I4Q36TKR9jSgAnaIvsFU=; b=IE6Kb5GEly2RGkpACdTwZ3d+W4pa+BR3N+o4d2j49YkHmS6KNHTqBY98X3IkMuba1f P2aomfULik4/hS6jY0G+cdHZkGaiWUdCn08Ddt9oa3aS2PbT504r6zJYRLxknzsZLpBX 9K7MKGvv14D5wN/0qWGKW4x3Y8b8brMNfwTanUIUTnWiUdUYDDa9ZQzs7qsrCU380347 p97eNyNB4j0ZpAZEqJmb8LP5/9XIWKqWNC4z9ozebTJEBTuHav3dTSmZ03R6TiRkg9k+ iMpj6w24hgQAM/hkj+9q84P4d0xjTicW5TmTLLrqRTa3QzEUTrAArzdWZlx0IUkRhmMQ uCDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=RmXuJD4qZhRM82pfRtozOF5I4Q36TKR9jSgAnaIvsFU=; b=kiGNAoUkWLuCJ7Xk9WpE5SJueYAnHciJXlH4XqFBmaKGCiBy89eat52bqEyzEgXS2h bvtrIJ8CbVDvB4bOVTUYbMLWUNiovUXVRATsHnTAzuN3wi4Df9vqccM5p0M03rxCicHJ /fVoHYDdAgV2214txYiTlVMYFWpyGLsrCfrvEYw3bE7o2RMaPPPIgNyl+xQqWztro0mJ eZbGEAxkVY6UxXpeTpqf0CX0MydZriQQKustY7uXIfi+Nlqdzadfu8Y0bgSthuevjBBx XL9VG0OaTd4DiE4ya4W//8trOltZqg7TI2trTnwnMnmGSPD4MTwWk2sZnRQ7vyGUlZYb SuOQ== X-Gm-Message-State: AOAM533wE3FistucFSe+njgESinnTHqAmg5GBvroQzyVqLPrOiAbdzZ2 DwDCOlzZzNmAJKnBa1QgxPu5+Q== X-Google-Smtp-Source: ABdhPJw5Q12+09m+TsdsuwZdO/QaOdBpDutmXMtjHeIdKREkr2cwkkLxUsqiU3mAMCv4XIa8aQBYpg== X-Received: by 2002:a5d:64a3:0:b0:203:d7e5:67ff with SMTP id m3-20020a5d64a3000000b00203d7e567ffmr36471260wrp.617.1648651528474; Wed, 30 Mar 2022 07:45:28 -0700 (PDT) Received: from elver.google.com ([2a00:79e0:15:13:c121:bc3e:9:bb31]) by smtp.gmail.com with ESMTPSA id f10-20020a0560001b0a00b0020402c09067sm11534659wrz.50.2022.03.30.07.45.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Mar 2022 07:45:27 -0700 (PDT) Date: Wed, 30 Mar 2022 16:45:22 +0200 From: Marco Elver To: Mark Rutland Cc: Jakub Jelinek , Segher Boessenkool , Peter Zijlstra , Nick Desaulniers , Borislav Petkov , Nathan Chancellor , x86-ml , lkml , llvm@lists.linux.dev, Josh Poimboeuf , linux-toolchains@vger.kernel.org Subject: Re: clang memcpy calls Message-ID: References: <20220325151238.GB614@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.1.4 (2021-12-11) Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Mon, Mar 28, 2022 at 02:44PM +0100, Mark Rutland wrote: [...] > From my PoV, distinguishing instrumentable/uninstrumentable calls at > compile time would be ideal. That, or placing the instrumentation into > the caller (omitting it when instrumentation is disabled for that > caller), and expecting the out-of-line forms are never instrumented. I > appreciate that latter option may not be workable due to potential size > bloat, though. That's what user space ASan with Clang already does: https://godbolt.org/z/ro1Y8E59e , where it prefixes mem*() calls with __asan_. Only -fsanitize=kernel-address has (unfortunately) been taught to omit the prefix. I don't have any info on the history of this, but given the issues that have surfaced in this thread, it's clearly the wrong thing. We'll be adding an option to undo this behaviour: https://reviews.llvm.org/D122724 It's unfortunate yet another option is required, but it's the only way to retain compatibility with older kernels that don't yet understand __asan_mem*() functions. For the kernel GCC then should also: 1. omit the prefix for `-fsanitize=kernel-address` (current behaviour) 2. add the prefix for `-fsanitize=kernel-address --param asan-kernel-mem-intrinsic-prefix` But because the ASan user space runtime already understands the __asan-prefixed versions, I imagine GCC can also do to align with Clang: 3. add the prefix for normal `-fsanitize=address` Thanks, -- Marco