From patchwork Thu Jun 24 03:40:47 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Axtens X-Patchwork-Id: 12340749 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=-16.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT 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 1820CC48BC2 for ; Thu, 24 Jun 2021 03:41:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B3E80613C5 for ; Thu, 24 Jun 2021 03:41:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B3E80613C5 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=axtens.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B95D26B0087; Wed, 23 Jun 2021 23:41:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B6C176B0088; Wed, 23 Jun 2021 23:41:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A348F8D0007; Wed, 23 Jun 2021 23:41:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0194.hostedemail.com [216.40.44.194]) by kanga.kvack.org (Postfix) with ESMTP id 6C8416B0087 for ; Wed, 23 Jun 2021 23:41:01 -0400 (EDT) Received: from smtpin39.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 9F132181AEF31 for ; Thu, 24 Jun 2021 03:41:01 +0000 (UTC) X-FDA: 78287216322.39.0EC5F80 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) by imf03.hostedemail.com (Postfix) with ESMTP id 3F58AC00CBE2 for ; Thu, 24 Jun 2021 03:41:01 +0000 (UTC) Received: by mail-pf1-f172.google.com with SMTP id t32so4029293pfg.2 for ; Wed, 23 Jun 2021 20:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axtens.net; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=sf2vC4DdejXn0TlyY78AewZhU0SgkUPuFBMazAbHZK4=; b=D8DjGwJUlXIO0TVrSG/ZeVvUPW8wAHpUnKMSvZFVHtop5C+89pYkyv+sH9hOpbRZu/ WeLrxWQk1TD4sCKNOKHTSyfqskGq5aaadsGnRaaDJz85jHEwhsY8ctxHqy/R1FXCJjVi YVLEC05DAfejjr8edszhWUuY6dHt2hgNoOS5c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=sf2vC4DdejXn0TlyY78AewZhU0SgkUPuFBMazAbHZK4=; b=su8KHkBOBK3Q78iajlkPJ6NrAmm8zuS9ZDg+b7hjTfflTonVQsm9cdaw5AjONcJUA1 e7Dp1P6ABevCz2CM3P5YdUE0IApndghggrnpm9lA8ZgFiTuzySj09lVkBRcmsS/czgIG yfoEUsa7fWIt4J/bQ8lkKn+YPN5xuk1HtlYbMRjk/TGwFnxiUwWREzaryPf+3YxQnc2c MNFZElGZdFgQMKa7T8s8srPvHqo7JqYMd0rTq+0r/9liOdn8vk++TgQDuRnS7Nv2dgPR ArYr/tZZuMBCkDl8xt77o727l17Lpx91mNkt099H7KgaFJjzgp9LdY/Bs6KmQfiNv7Ad IsRg== X-Gm-Message-State: AOAM532IT6gIQ1NzFAjmPuC/CoajW1kn6GuvMWkreXxeXoGgmlWUnBeZ 6H7rbplOXfoQbBviN8PXTPNv3w== X-Google-Smtp-Source: ABdhPJxwUXidQSW66Cd7hfNHu9m1OdS3iDnW9VrYoHaD9hKo1tsw6JFDwPcDmznjLKOpOobVgqPCDg== X-Received: by 2002:a05:6a00:138f:b029:304:2af5:1e12 with SMTP id t15-20020a056a00138fb02903042af51e12mr3014900pfg.5.1624506060335; Wed, 23 Jun 2021 20:41:00 -0700 (PDT) Received: from localhost ([203.206.29.204]) by smtp.gmail.com with ESMTPSA id p6sm6789262pjh.24.2021.06.23.20.40.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Jun 2021 20:41:00 -0700 (PDT) From: Daniel Axtens To: linux-kernel@vger.kernel.org, linux-mm@kvack.org, kasan-dev@googlegroups.com, elver@google.com, akpm@linux-foundation.org, andreyknvl@gmail.com Cc: linuxppc-dev@lists.ozlabs.org, christophe.leroy@csgroup.eu, aneesh.kumar@linux.ibm.com, bsingharora@gmail.com, Daniel Axtens Subject: [PATCH v16 1/4] kasan: allow an architecture to disable inline instrumentation Date: Thu, 24 Jun 2021 13:40:47 +1000 Message-Id: <20210624034050.511391-2-dja@axtens.net> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20210624034050.511391-1-dja@axtens.net> References: <20210624034050.511391-1-dja@axtens.net> MIME-Version: 1.0 Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=axtens.net header.s=google header.b=D8DjGwJU; spf=pass (imf03.hostedemail.com: domain of dja@axtens.net designates 209.85.210.172 as permitted sender) smtp.mailfrom=dja@axtens.net; dmarc=none X-Stat-Signature: ma19jwt85f8kkw979ftqm4xp3df6csmm X-Rspamd-Queue-Id: 3F58AC00CBE2 X-Rspamd-Server: rspam06 X-HE-Tag: 1624506061-685715 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: 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 Reviewed-by: Andrey Konovalov --- lib/Kconfig.kasan | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan index cffc2ebbf185..c3b228828a80 100644 --- a/lib/Kconfig.kasan +++ b/lib/Kconfig.kasan @@ -12,6 +12,13 @@ config HAVE_ARCH_KASAN_HW_TAGS config HAVE_ARCH_KASAN_VMALLOC bool +config ARCH_DISABLE_KASAN_INLINE + bool + help + An architecture might not support inline instrumentation. + When this option is selected, inline and stack instrumentation are + disabled. + config CC_HAS_KASAN_GENERIC def_bool $(cc-option, -fsanitize=kernel-address) @@ -130,6 +137,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 +149,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 +163,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, stack + instrumentation is also disabled as it adds inline-style + instrumentation that is run unconditionally. config KASAN_SW_TAGS_IDENTIFY bool "Enable memory corruption identification"