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 C385BC636CC for ; Mon, 13 Feb 2023 13:38:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230183AbjBMNiX (ORCPT ); Mon, 13 Feb 2023 08:38:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43682 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229671AbjBMNiW (ORCPT ); Mon, 13 Feb 2023 08:38:22 -0500 Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1B5F618B0E for ; Mon, 13 Feb 2023 05:38:20 -0800 (PST) Received: by mail-vk1-xa31.google.com with SMTP id bs10so6255082vkb.3 for ; Mon, 13 Feb 2023 05:38:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1676295499; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QiocV00En5D5cLXBZHTCzW16cVc0Pj8et9mT/H0L18Y=; b=HxTUETCUsjJ18Q9E4rFJV4FjWTaROLW3+AtHothjcu7bNoPaqml3RyiyTic08AYEpk jTFHU7hGK8/gc9MK1yXPO6ShAH3XJqr4G9jDRAAh5zQWysE8Q/M8BJcagkLGNCLCD4Qg aGnzn6botuEeOo9CddWeqM7bd5+8V8M9cjam2jQ4o/YBMKzF5JQwdkJP7q5kwcJMutRN 5jVj1e2Qum6g48RK3buasXKXSfqwrZITbCcAE5y0naCNG/krgYMUK4792vZRMMXunqEe 19GMrMjdgnUCPZVH3MSfw7LGROB6nku1tyESlO8FzoEVPLtbm+RGQ4xNbDabQu+/UGxL osEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1676295499; 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=QiocV00En5D5cLXBZHTCzW16cVc0Pj8et9mT/H0L18Y=; b=y9XFbDAaZtyQt5hHz3BW5f3Uc239/P8LdY9xKQ2S7O6iNRgmXhGcPjk1zCK3G+Y7P3 KiuNN64bw/O6KHOGMvfaB6TaCQrFlG7OSEG+CUiuI329U7GVXDs1ZiuSK9sxdzuXngGt cZ/r/E5JspXLQz9DZLeendaK+G7Hdk1Arjscsnh36Q7QvQaGGgzjikCk/8wnDLR6KVUq uYxqh7YPhLmUHYLIJJW9w/BHYfLHcFXAlqKgUzj5aXtOY4K6ryI9gBbaABHukp1l7e6I XfClSfde7N8TSEyOLwbVbX/pqFozc2ozLImuJbDDXSY0khDUFaJoslImMv9aZoNUb+1h HM0A== X-Gm-Message-State: AO0yUKW0B4W/nyav6pYR074iyetHPBwp/ElyA5sZmnhygNfBgoNUjoT9 WY32gGKVeX1B1O2gaFMb2nC73de5vLSvmY06AbmahA== X-Google-Smtp-Source: AK7set/l3c8GmYteAMqSJ6SPYkS1v+afgnQO1saFsyMt/OzFIAUcb8IlbO8CA0+xxyWvCN279WdrtcqJghM37ky6Zuk= X-Received: by 2002:a1f:2bd0:0:b0:3e8:a035:4860 with SMTP id r199-20020a1f2bd0000000b003e8a0354860mr4437186vkr.7.1676295499037; Mon, 13 Feb 2023 05:38:19 -0800 (PST) MIME-Version: 1.0 References: <20230208184203.2260394-1-elver@google.com> In-Reply-To: From: Marco Elver Date: Mon, 13 Feb 2023 14:37:42 +0100 Message-ID: Subject: Re: [PATCH -tip] kasan: Emit different calls for instrumentable memintrinsics To: Peter Zijlstra Cc: Jakub Jelinek , 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 Mon, 13 Feb 2023 at 13:36, Peter Zijlstra wrote: > > On Mon, Feb 13, 2023 at 12:01:40PM +0100, Jakub Jelinek wrote: > > > The current gcc behavior is that operations like aggregate copies, or > > clearing which might or might not need memcpy/memset/memmove under the hood > > later are asan instrumented before the operation (in order not to limit the > > choices on how it will be expanded), uses of builtins (__builtin_ prefixed > > or not) are also instrumented before the calls unless they are one of the > > calls that is recognized as always instrumented. None for hwasan, > > for asan: > > index, memchr, memcmp, memcpy, memmove, memset, strcasecmp, strcat, strchr, > > strcmp, strcpy, strdup, strlen, strncasecmp, strncat, strncmp, strcspn, > > strpbrk, strspn, strstr, strncpy > > and for those builtins gcc disables inline expansion and enforces a library > > call (but until the expansion they are treated in optimizations like normal > > builtins and so could be say DCEd, or their aliasing behavior is considered > > etc.). kasan behaves the same I think. > > > > Now, I think libasan only has __asan_ prefixed > > __asan_memmove, __asan_memset and __asan_memcpy, nothing else, so most of > > the calls from the above list even can't be prefixed. Correct, right now libasan only does memmove, memset, and memcpy. I don't think it'll ever do more, at least not in the near future. > > So, do you want for --param asan-kernel-mem-intrinsic-prefix=1 to __asan_ > > prefix just memcpy/memmove/memset and nothing else? Yes. > > Is it ok to emit > > memcpy/memset/memmove from aggregate operations which are instrumented > > already at the caller (and similarly is it ok to handle those operations > > inline)? Yes, I think that's fair. > I'm thinking it is trivial to add more __asan prefixed functions as > needed, while trying to untangle the trainwreck created by assuming the > normal functions are instrumented is much more work. For the kernel param, I'd only do memcpy/memmove/memset, as those are the most brittle ones. The string functions are instrumented on most architectures through lib/string.c being instrumented. Thanks, -- Marco