From patchwork Thu Jun 17 06:39:53 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Axtens X-Patchwork-Id: 12326861 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 9980AC2B9F4 for ; Thu, 17 Jun 2021 06:40:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 10E5A6101A for ; Thu, 17 Jun 2021 06:40:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 10E5A6101A 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 A2D6A6B0071; Thu, 17 Jun 2021 02:40:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A04436B0072; Thu, 17 Jun 2021 02:40:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 85A4B6B0073; Thu, 17 Jun 2021 02:40:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0209.hostedemail.com [216.40.44.209]) by kanga.kvack.org (Postfix) with ESMTP id 4E4DC6B0071 for ; Thu, 17 Jun 2021 02:40:10 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id D6ED019B2D for ; Thu, 17 Jun 2021 06:40:09 +0000 (UTC) X-FDA: 78262266138.14.47CF9E0 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by imf18.hostedemail.com (Postfix) with ESMTP id 944662001097 for ; Thu, 17 Jun 2021 06:39:59 +0000 (UTC) Received: by mail-pl1-f174.google.com with SMTP id c15so2314319pls.13 for ; Wed, 16 Jun 2021 23:40:09 -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=FhcxQma+NItwG5Mp37m/KF4tp14MA8dMkKZlGGIww7w=; b=NX/qvxr8dhuE37o1z5sgt2XG3iamjEnXiWs3Cjuob6iS4N7i54VKlfizgYe8xGGkPG ECD5YCGaTs51KaCl4epayh0dHJ+o8LndpifLgVU7jrsZXsK+fxf956QA+f9kaEQexM97 ESKPsh4uIbJJ1pXHDwjoTPF3Wsz2Knn+hfVYc= 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=FhcxQma+NItwG5Mp37m/KF4tp14MA8dMkKZlGGIww7w=; b=Gb/WBKsyZE4izt1XPYts2ZmIlVz5kTyamhdE4ZSkAZ+p0NxWjeYPmpRLHzSIGnaDvq P5h035aV57OXRcax2aseBWU4NySgvBToh9Q12P9TIXWwIA2cuVG2o4CMcutNtEoJU5i6 di1D4o+68KDODrJTS83zzO0kaXcqnKGnKChp5GTL4dhnB5i/xwbb9fOMky2WbuOmedHm XGkPAKJsAoYvIehbI00AMIkLxLkeD9yGTH3eCb/UI0sSFimVC3p0xzOrCmibkb7fM+im /fqTRxaD7l1UHyMvPzTjPMdp7XAGn97JN+H42FFCjiqiLAMR7EFMtYkcyZ1LukW7ZBYV ZJ9A== X-Gm-Message-State: AOAM533vq4rwogHW7gdPVsZdlziISozaVOkWooc52mSot7/VHMdORlLE SjEajIkKK7693M1zrIrw6nO5mw== X-Google-Smtp-Source: ABdhPJzfeN5byN4YxzyNu/GjCulyBlU25iQrctXCoCFZvJ5L0B+A23QQj4gHY87HwYK24nhSnOkqEg== X-Received: by 2002:a17:90b:38ca:: with SMTP id nn10mr4147573pjb.127.1623912008754; Wed, 16 Jun 2021 23:40:08 -0700 (PDT) Received: from localhost ([203.206.29.204]) by smtp.gmail.com with ESMTPSA id d12sm3987316pfo.113.2021.06.16.23.40.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Jun 2021 23:40:08 -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 v14 1/4] kasan: allow an architecture to disable inline instrumentation Date: Thu, 17 Jun 2021 16:39:53 +1000 Message-Id: <20210617063956.94061-2-dja@axtens.net> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20210617063956.94061-1-dja@axtens.net> References: <20210617063956.94061-1-dja@axtens.net> MIME-Version: 1.0 Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=axtens.net header.s=google header.b="NX/qvxr8"; spf=pass (imf18.hostedemail.com: domain of dja@axtens.net designates 209.85.214.174 as permitted sender) smtp.mailfrom=dja@axtens.net; dmarc=none X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 944662001097 X-Stat-Signature: 7w31f1x4s84mk3uq3er9upcmwseyhboy X-HE-Tag: 1623911999-693540 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. Signed-off-by: Daniel Axtens Reviewed-by: Marco Elver --- 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. + + 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 + also disabled as it adds inline-style instrumentation that + is run unconditionally. config KASAN_SW_TAGS_IDENTIFY bool "Enable memory corruption identification"