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 X-Spam-Level: X-Spam-Status: No, score=-12.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3CA78C48BDF for ; Sun, 20 Jun 2021 11:16:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1CB4F6023E for ; Sun, 20 Jun 2021 11:16:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229608AbhFTLS0 (ORCPT ); Sun, 20 Jun 2021 07:18:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38300 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229541AbhFTLSX (ORCPT ); Sun, 20 Jun 2021 07:18:23 -0400 Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DA365C061574 for ; Sun, 20 Jun 2021 04:16:08 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id r7so14880658edv.12 for ; Sun, 20 Jun 2021 04:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V5/7gChl8XVHJy56wbmIvB0M6WNYjYtPIXj58muV060=; b=jN/BusFBAy0H0K8XICbKokRtXvE46Jg9wWHv6C3yKJ4ltpqDJcQGhZ1eGePUBuJpcD GVxy6L/KfghmPpoSd2s77Z8Zw2PNKoXTFC7Vc4efp7591Uwv6OKlhUDLZI9OodjSCUpE MolIufzAU533+EeMqNY33zlNltq8XndJxXofqolSSAyJP8+RQPEm54nwOhapMtA9d7bX MEBe4KrOtHSXD25IZkebvvqyDUw++ST0DGBen5Hg4H7v8bUWgx9ebTGF9Hu/m7OB7aKy szK7be9Uymxn+Z94tuUlyy6luSg1iXknyktYtOcMD7rRST/QhbxXSU4EOWhld50Zga9y DFMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V5/7gChl8XVHJy56wbmIvB0M6WNYjYtPIXj58muV060=; b=en9guqgu770f8SjZCOwef5DG0ay55/ruaTHLz1Cq8LZEWaLtdOAxdcRhM5o/Ot4lyn XW/iFBPeMudnxA/lMtyrRomWU3TyyZ1ASNnHZDBjalgbeLqbbKwgQUXPtmLkDgrh29lc Pl5abqUpQc6gmJArTTa2iSTJ+7zu+oCYBEVucS8MHjsxp81RESv1lo5kkEszg2FPKbWQ MOIDtP3etv1ON3tki4nrMMCnf7TU1wH3mZV3/hlIxa7oj5gbXEzMhoxCWH/ubdnqkscQ IyDJb3nBYwQUkMmYT0siYRL6qGyeMBKFUjOewfqzbhdpcN3DdcWu1DpGTcaRxLP0ZCC2 jZRw== X-Gm-Message-State: AOAM531jdbpdSJRdC5dUnnxzNwv54WwRX3hbOwKo3vCuajp/8kxb5L2J +UbJvXoY4sN/KZUriU4EFonfuSDv9yEiwuiadTE= X-Google-Smtp-Source: ABdhPJz937pStinuTEs3ZLpQqCjCRjkm2e7k2G+o2w9JlMneIbvvO44fP0ffJTE/fw1xSG2QWrOyaAGXJfP/zvvi5Rc= X-Received: by 2002:a05:6402:42d2:: with SMTP id i18mr15359424edc.168.1624187767478; Sun, 20 Jun 2021 04:16:07 -0700 (PDT) MIME-Version: 1.0 References: <20210617093032.103097-1-dja@axtens.net> <20210617093032.103097-2-dja@axtens.net> In-Reply-To: <20210617093032.103097-2-dja@axtens.net> From: Andrey Konovalov Date: Sun, 20 Jun 2021 14:15:47 +0300 Message-ID: Subject: Re: [PATCH v15 1/4] kasan: allow an architecture to disable inline instrumentation To: Daniel Axtens Cc: LKML , Linux Memory Management List , kasan-dev , Marco Elver , Andrew Morton , linuxppc-dev@lists.ozlabs.org, christophe.leroy@csgroup.eu, aneesh.kumar@linux.ibm.com, bsingharora@gmail.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 17, 2021 at 12:30 PM Daniel Axtens wrote: > > For annoying architectural reasons, it's very difficult to support inline > instrumentation on powerpc64.* > > Add a Kconfig flag to allow an arch to disable inline. (It's a bit > annoying to be 'backwards', but I'm not aware of any way to have > an arch force a symbol to be 'n', rather than 'y'.) > > We also disable stack instrumentation in this case as it does things that > are functionally equivalent to inline instrumentation, namely adding > code that touches the shadow directly without going through a C helper. > > * on ppc64 atm, the shadow lives in virtual memory and isn't accessible in > real mode. However, before we turn on virtual memory, we parse the device > tree to determine which platform and MMU we're running under. That calls > generic DT code, which is instrumented. Inline instrumentation in DT would > unconditionally attempt to touch the shadow region, which we won't have > set up yet, and would crash. We can make outline mode wait for the arch to > be ready, but we can't change what the compiler inserts for inline mode. > > Reviewed-by: Marco Elver > Signed-off-by: Daniel Axtens > --- > lib/Kconfig.kasan | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan > index cffc2ebbf185..cb5e02d09e11 100644 > --- a/lib/Kconfig.kasan > +++ b/lib/Kconfig.kasan > @@ -12,6 +12,15 @@ config HAVE_ARCH_KASAN_HW_TAGS > config HAVE_ARCH_KASAN_VMALLOC > bool > > +config ARCH_DISABLE_KASAN_INLINE > + bool > + help > + Sometimes an architecture might not be able to support inline > + instrumentation but might be able to support outline instrumentation. > + This option allows an architecture to prevent inline and stack > + instrumentation from being enabled. This seems too wordy. How about: "An architecture might not support inline instrumentation. When this option is selected, inline and stack instrumentation are disabled." > + > + Drop the extra empty line. > config CC_HAS_KASAN_GENERIC > def_bool $(cc-option, -fsanitize=kernel-address) > > @@ -130,6 +139,7 @@ config KASAN_OUTLINE > > config KASAN_INLINE > bool "Inline instrumentation" > + depends on !ARCH_DISABLE_KASAN_INLINE > help > Compiler directly inserts code checking shadow memory before > memory accesses. This is faster than outline (in some workloads > @@ -141,6 +151,7 @@ endchoice > config KASAN_STACK > bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST > depends on KASAN_GENERIC || KASAN_SW_TAGS > + depends on !ARCH_DISABLE_KASAN_INLINE > default y if CC_IS_GCC > help > The LLVM stack address sanitizer has a know problem that > @@ -154,6 +165,9 @@ config KASAN_STACK > but clang users can still enable it for builds without > CONFIG_COMPILE_TEST. On gcc it is assumed to always be safe > to use and enabled by default. > + If the architecture disables inline instrumentation, this is this => stack instrumentation > + also disabled as it adds inline-style instrumentation that > + is run unconditionally. > > config KASAN_SW_TAGS_IDENTIFY > bool "Enable memory corruption identification" > -- > 2.30.2 > 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 X-Spam-Level: X-Spam-Status: No, score=-12.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 267D3C48BDF for ; Sun, 20 Jun 2021 11:16:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A44366102A for ; Sun, 20 Jun 2021 11:16:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A44366102A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DA2176B006E; Sun, 20 Jun 2021 07:16:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D2B726B0070; Sun, 20 Jun 2021 07:16:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B7D576B0072; Sun, 20 Jun 2021 07:16:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0136.hostedemail.com [216.40.44.136]) by kanga.kvack.org (Postfix) with ESMTP id 7E6856B006E for ; Sun, 20 Jun 2021 07:16:09 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 278B9180AD81F for ; Sun, 20 Jun 2021 11:16:09 +0000 (UTC) X-FDA: 78273848058.14.8839A35 Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) by imf18.hostedemail.com (Postfix) with ESMTP id C8C782001132 for ; Sun, 20 Jun 2021 11:16:08 +0000 (UTC) Received: by mail-ed1-f45.google.com with SMTP id i13so14904305edb.9 for ; Sun, 20 Jun 2021 04:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V5/7gChl8XVHJy56wbmIvB0M6WNYjYtPIXj58muV060=; b=jN/BusFBAy0H0K8XICbKokRtXvE46Jg9wWHv6C3yKJ4ltpqDJcQGhZ1eGePUBuJpcD GVxy6L/KfghmPpoSd2s77Z8Zw2PNKoXTFC7Vc4efp7591Uwv6OKlhUDLZI9OodjSCUpE MolIufzAU533+EeMqNY33zlNltq8XndJxXofqolSSAyJP8+RQPEm54nwOhapMtA9d7bX MEBe4KrOtHSXD25IZkebvvqyDUw++ST0DGBen5Hg4H7v8bUWgx9ebTGF9Hu/m7OB7aKy szK7be9Uymxn+Z94tuUlyy6luSg1iXknyktYtOcMD7rRST/QhbxXSU4EOWhld50Zga9y DFMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V5/7gChl8XVHJy56wbmIvB0M6WNYjYtPIXj58muV060=; b=pdvaZegUJBTZNmKJd1RvU+bEvUsB6u2aISaVrbX6GcsceFfyMbpenIV7LMbcEyD8dI HQJFPSeuYeYLqEbUid2loytbTa5TGWoaN8MEBgvmAGsV12xG+WaPOFw0ucrJAdSwuwS/ CfO4OgYLHBeVFdV8zAWHpqWRAe54OOXYJVkaeeph2ozG3Alfx3R/Sj+CvxmpjBBar/FD G+oTaUPxoyTGrEw9iFokB9a8Sv9r0xiqb3Dssb2/82S9V8n+0AeRaW4KyW35dAolAdN9 P6g6/KaHw0422RXXGsR3+gSIZZQmLkWSWsMaFOcULtdXzYLFjH+KVy1IoM4yH0kHoga5 epDQ== X-Gm-Message-State: AOAM533Tbg2tEo8rWf2q34/LC4ANOrnhg3HL4lvJtTx35+NbFx81YCAq 8UIWmKbPn/W14ZmMtYXMWg+r/sOzLvGYYBzQWZ0= X-Google-Smtp-Source: ABdhPJz937pStinuTEs3ZLpQqCjCRjkm2e7k2G+o2w9JlMneIbvvO44fP0ffJTE/fw1xSG2QWrOyaAGXJfP/zvvi5Rc= X-Received: by 2002:a05:6402:42d2:: with SMTP id i18mr15359424edc.168.1624187767478; Sun, 20 Jun 2021 04:16:07 -0700 (PDT) MIME-Version: 1.0 References: <20210617093032.103097-1-dja@axtens.net> <20210617093032.103097-2-dja@axtens.net> In-Reply-To: <20210617093032.103097-2-dja@axtens.net> From: Andrey Konovalov Date: Sun, 20 Jun 2021 14:15:47 +0300 Message-ID: Subject: Re: [PATCH v15 1/4] kasan: allow an architecture to disable inline instrumentation To: Daniel Axtens Cc: LKML , Linux Memory Management List , kasan-dev , Marco Elver , Andrew Morton , linuxppc-dev@lists.ozlabs.org, christophe.leroy@csgroup.eu, aneesh.kumar@linux.ibm.com, bsingharora@gmail.com Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b="jN/BusFB"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.208.45 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com X-Rspamd-Server: rspam02 X-Stat-Signature: 6e6191bzyfwbn3bdnnfk1tyayrwio6ff X-Rspamd-Queue-Id: C8C782001132 X-HE-Tag: 1624187768-788453 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Jun 17, 2021 at 12:30 PM Daniel Axtens wrote: > > For annoying architectural reasons, it's very difficult to support inline > instrumentation on powerpc64.* > > Add a Kconfig flag to allow an arch to disable inline. (It's a bit > annoying to be 'backwards', but I'm not aware of any way to have > an arch force a symbol to be 'n', rather than 'y'.) > > We also disable stack instrumentation in this case as it does things that > are functionally equivalent to inline instrumentation, namely adding > code that touches the shadow directly without going through a C helper. > > * on ppc64 atm, the shadow lives in virtual memory and isn't accessible in > real mode. However, before we turn on virtual memory, we parse the device > tree to determine which platform and MMU we're running under. That calls > generic DT code, which is instrumented. Inline instrumentation in DT would > unconditionally attempt to touch the shadow region, which we won't have > set up yet, and would crash. We can make outline mode wait for the arch to > be ready, but we can't change what the compiler inserts for inline mode. > > Reviewed-by: Marco Elver > Signed-off-by: Daniel Axtens > --- > lib/Kconfig.kasan | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan > index cffc2ebbf185..cb5e02d09e11 100644 > --- a/lib/Kconfig.kasan > +++ b/lib/Kconfig.kasan > @@ -12,6 +12,15 @@ config HAVE_ARCH_KASAN_HW_TAGS > config HAVE_ARCH_KASAN_VMALLOC > bool > > +config ARCH_DISABLE_KASAN_INLINE > + bool > + help > + Sometimes an architecture might not be able to support inline > + instrumentation but might be able to support outline instrumentation. > + This option allows an architecture to prevent inline and stack > + instrumentation from being enabled. This seems too wordy. How about: "An architecture might not support inline instrumentation. When this option is selected, inline and stack instrumentation are disabled." > + > + Drop the extra empty line. > config CC_HAS_KASAN_GENERIC > def_bool $(cc-option, -fsanitize=kernel-address) > > @@ -130,6 +139,7 @@ config KASAN_OUTLINE > > config KASAN_INLINE > bool "Inline instrumentation" > + depends on !ARCH_DISABLE_KASAN_INLINE > help > Compiler directly inserts code checking shadow memory before > memory accesses. This is faster than outline (in some workloads > @@ -141,6 +151,7 @@ endchoice > config KASAN_STACK > bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST > depends on KASAN_GENERIC || KASAN_SW_TAGS > + depends on !ARCH_DISABLE_KASAN_INLINE > default y if CC_IS_GCC > help > The LLVM stack address sanitizer has a know problem that > @@ -154,6 +165,9 @@ config KASAN_STACK > but clang users can still enable it for builds without > CONFIG_COMPILE_TEST. On gcc it is assumed to always be safe > to use and enabled by default. > + If the architecture disables inline instrumentation, this is this => stack instrumentation > + also disabled as it adds inline-style instrumentation that > + is run unconditionally. > > config KASAN_SW_TAGS_IDENTIFY > bool "Enable memory corruption identification" > -- > 2.30.2 > 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 X-Spam-Level: X-Spam-Status: No, score=-10.5 required=3.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AA170C48BDF for ; Sun, 20 Jun 2021 11:46:30 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EE9FD61003 for ; Sun, 20 Jun 2021 11:46:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EE9FD61003 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4G79q86KsSz30BP for ; Sun, 20 Jun 2021 21:46:28 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20161025 header.b=jN/BusFB; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2a00:1450:4864:20::533; helo=mail-ed1-x533.google.com; envelope-from=andreyknvl@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20161025 header.b=jN/BusFB; dkim-atps=neutral Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4G798L2wv2z2yyG for ; Sun, 20 Jun 2021 21:16:16 +1000 (AEST) Received: by mail-ed1-x533.google.com with SMTP id h2so1412493edt.3 for ; Sun, 20 Jun 2021 04:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V5/7gChl8XVHJy56wbmIvB0M6WNYjYtPIXj58muV060=; b=jN/BusFBAy0H0K8XICbKokRtXvE46Jg9wWHv6C3yKJ4ltpqDJcQGhZ1eGePUBuJpcD GVxy6L/KfghmPpoSd2s77Z8Zw2PNKoXTFC7Vc4efp7591Uwv6OKlhUDLZI9OodjSCUpE MolIufzAU533+EeMqNY33zlNltq8XndJxXofqolSSAyJP8+RQPEm54nwOhapMtA9d7bX MEBe4KrOtHSXD25IZkebvvqyDUw++ST0DGBen5Hg4H7v8bUWgx9ebTGF9Hu/m7OB7aKy szK7be9Uymxn+Z94tuUlyy6luSg1iXknyktYtOcMD7rRST/QhbxXSU4EOWhld50Zga9y DFMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V5/7gChl8XVHJy56wbmIvB0M6WNYjYtPIXj58muV060=; b=Mq9tgQ41CaE3fHrMDhhbvbX3Zphh+dZie81siO+Bfdjfet283vzSnCf0vunVkGtYeq mia6YNrZVBIqqsktnMQWxcj5XtD6U7E28nuwxi87mhBevQTMnya9UIqcgKpG3HFq0iXJ rMQGw2chA+fqLiMNkjo/c6GxFmFO/kc2rShJzXbTfwq8SS6nUpYzlkrwcutY/5EvPK88 2Ev0rIEp9HJ6v4vqomwC6abCnTQ/H5Dn9O90l9S7DL+SDutXedGZK+TA39aN9MU7Wxxx U0I9oSCIEQvgcTLTW3n2GXWbsPQgNt0jnRWlHtVFtib2aMuvOlSzGZVt4HoZhwuUP2PF 91Jw== X-Gm-Message-State: AOAM533TxCCNli4UypZm28W3BEWWgnFzYsN3nkRE7DjdUmqNDnxvyhpM 2UTzdub/x5aS24lmPcjh1hfK1SrCNH6zGOfXnyw= X-Google-Smtp-Source: ABdhPJz937pStinuTEs3ZLpQqCjCRjkm2e7k2G+o2w9JlMneIbvvO44fP0ffJTE/fw1xSG2QWrOyaAGXJfP/zvvi5Rc= X-Received: by 2002:a05:6402:42d2:: with SMTP id i18mr15359424edc.168.1624187767478; Sun, 20 Jun 2021 04:16:07 -0700 (PDT) MIME-Version: 1.0 References: <20210617093032.103097-1-dja@axtens.net> <20210617093032.103097-2-dja@axtens.net> In-Reply-To: <20210617093032.103097-2-dja@axtens.net> From: Andrey Konovalov Date: Sun, 20 Jun 2021 14:15:47 +0300 Message-ID: Subject: Re: [PATCH v15 1/4] kasan: allow an architecture to disable inline instrumentation To: Daniel Axtens Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Sun, 20 Jun 2021 21:46:05 +1000 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Marco Elver , aneesh.kumar@linux.ibm.com, LKML , kasan-dev , Linux Memory Management List , Andrew Morton , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Thu, Jun 17, 2021 at 12:30 PM Daniel Axtens wrote: > > For annoying architectural reasons, it's very difficult to support inline > instrumentation on powerpc64.* > > Add a Kconfig flag to allow an arch to disable inline. (It's a bit > annoying to be 'backwards', but I'm not aware of any way to have > an arch force a symbol to be 'n', rather than 'y'.) > > We also disable stack instrumentation in this case as it does things that > are functionally equivalent to inline instrumentation, namely adding > code that touches the shadow directly without going through a C helper. > > * on ppc64 atm, the shadow lives in virtual memory and isn't accessible in > real mode. However, before we turn on virtual memory, we parse the device > tree to determine which platform and MMU we're running under. That calls > generic DT code, which is instrumented. Inline instrumentation in DT would > unconditionally attempt to touch the shadow region, which we won't have > set up yet, and would crash. We can make outline mode wait for the arch to > be ready, but we can't change what the compiler inserts for inline mode. > > Reviewed-by: Marco Elver > Signed-off-by: Daniel Axtens > --- > lib/Kconfig.kasan | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan > index cffc2ebbf185..cb5e02d09e11 100644 > --- a/lib/Kconfig.kasan > +++ b/lib/Kconfig.kasan > @@ -12,6 +12,15 @@ config HAVE_ARCH_KASAN_HW_TAGS > config HAVE_ARCH_KASAN_VMALLOC > bool > > +config ARCH_DISABLE_KASAN_INLINE > + bool > + help > + Sometimes an architecture might not be able to support inline > + instrumentation but might be able to support outline instrumentation. > + This option allows an architecture to prevent inline and stack > + instrumentation from being enabled. This seems too wordy. How about: "An architecture might not support inline instrumentation. When this option is selected, inline and stack instrumentation are disabled." > + > + Drop the extra empty line. > config CC_HAS_KASAN_GENERIC > def_bool $(cc-option, -fsanitize=kernel-address) > > @@ -130,6 +139,7 @@ config KASAN_OUTLINE > > config KASAN_INLINE > bool "Inline instrumentation" > + depends on !ARCH_DISABLE_KASAN_INLINE > help > Compiler directly inserts code checking shadow memory before > memory accesses. This is faster than outline (in some workloads > @@ -141,6 +151,7 @@ endchoice > config KASAN_STACK > bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST > depends on KASAN_GENERIC || KASAN_SW_TAGS > + depends on !ARCH_DISABLE_KASAN_INLINE > default y if CC_IS_GCC > help > The LLVM stack address sanitizer has a know problem that > @@ -154,6 +165,9 @@ config KASAN_STACK > but clang users can still enable it for builds without > CONFIG_COMPILE_TEST. On gcc it is assumed to always be safe > to use and enabled by default. > + If the architecture disables inline instrumentation, this is this => stack instrumentation > + also disabled as it adds inline-style instrumentation that > + is run unconditionally. > > config KASAN_SW_TAGS_IDENTIFY > bool "Enable memory corruption identification" > -- > 2.30.2 >