From patchwork Tue Jun 15 01:47:00 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Axtens X-Patchwork-Id: 12320381 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 93988C2B9F4 for ; Tue, 15 Jun 2021 01:47:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 36B3561412 for ; Tue, 15 Jun 2021 01:47:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 36B3561412 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 AD9CC6B006E; Mon, 14 Jun 2021 21:47:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A8A9D6B0070; Mon, 14 Jun 2021 21:47:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8DC826B0071; Mon, 14 Jun 2021 21:47:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0018.hostedemail.com [216.40.44.18]) by kanga.kvack.org (Postfix) with ESMTP id 5B20C6B006E for ; Mon, 14 Jun 2021 21:47:18 -0400 (EDT) Received: from smtpin36.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 788E18249980 for ; Tue, 15 Jun 2021 01:47:16 +0000 (UTC) X-FDA: 78254270472.36.A206C96 Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176]) by imf13.hostedemail.com (Postfix) with ESMTP id A4005E000243 for ; Tue, 15 Jun 2021 01:47:07 +0000 (UTC) Received: by mail-pg1-f176.google.com with SMTP id v7so1396289pgl.2 for ; Mon, 14 Jun 2021 18:47:15 -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=HOnQVo+SWV1H037ZQ/Ye/PGWwO/+/ZmfPhIlu9wOFzQ=; b=Pn6LBDzCFlVrC5tuz8fdMSLA0HjWfz1US+FJjBB7jTX/aufzoPNc6EjedXxxY3BLMm f1gHqD2r7QzoTO/8zt6a6IKMk0pOk/rHbExmfnwH8S/kFT/dQavV3mAeyh6n3hZDwmMZ IWjGf9JK/AoOfUpQ6+dnwlZ5SN8MwCTEraPZs= 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=HOnQVo+SWV1H037ZQ/Ye/PGWwO/+/ZmfPhIlu9wOFzQ=; b=A/JSKgDXPrk+5Z01G+IizNHzCuDl39HEoG7DX2Ox0w3V9mzfDDHM944qtIkZejMoO6 i17uexzz5HpFenlh7FWpbablrKVrMRck7cU0jubIAyS5qbzyg+ekiU79xWXl+Sx7Z8Ri ch9Dc8B5m/cnq/pyr+BwbWG0uo/w5XLbH2Q6jqWsmLuxh9yHERC+RjFaQiFfFjwQZg3V ETgTZnacuZ6caCn9DkY0sa/AQtThFM0ntPZ1HqZVVIuOC3VDaKyhii1WLtJYxfngDzZo Gwj9FGHE7xZGZB9rx3b+NahJCi4lPnciL8Am3wMjKwy0fBsTx5YWVuwh2AfGoKYLnQBa huvQ== X-Gm-Message-State: AOAM530dGifnA/pmtDArJBSkvdt4jkH9shAk32egHb0pUMm/waru3qKl wcQF3IE47f4vKw4unVXx41IZQg== X-Google-Smtp-Source: ABdhPJwqctJ4sje6V13eMdiiU5VjjfvVBqRlbjJUu+6/rSMEDip5D7XD4vGAToI0HE9b5nehhcU7rQ== X-Received: by 2002:a65:66cf:: with SMTP id c15mr14734452pgw.121.1623721635179; Mon, 14 Jun 2021 18:47:15 -0700 (PDT) Received: from localhost ([203.206.29.204]) by smtp.gmail.com with ESMTPSA id gk21sm13168157pjb.22.2021.06.14.18.47.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Jun 2021 18:47:14 -0700 (PDT) From: Daniel Axtens To: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, kasan-dev@googlegroups.com, christophe.leroy@csgroup.eu, aneesh.kumar@linux.ibm.com, bsingharora@gmail.com Cc: elver@google.com, Daniel Axtens Subject: [PATCH v12 1/6] kasan: allow an architecture to disable inline instrumentation Date: Tue, 15 Jun 2021 11:47:00 +1000 Message-Id: <20210615014705.2234866-2-dja@axtens.net> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20210615014705.2234866-1-dja@axtens.net> References: <20210615014705.2234866-1-dja@axtens.net> MIME-Version: 1.0 Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=axtens.net header.s=google header.b=Pn6LBDzC; spf=pass (imf13.hostedemail.com: domain of dja@axtens.net designates 209.85.215.176 as permitted sender) smtp.mailfrom=dja@axtens.net; dmarc=none X-Stat-Signature: hepr3a6h94cupfcbxnga1ush7eqcz5h1 X-Rspamd-Queue-Id: A4005E000243 X-Rspamd-Server: rspam06 X-HE-Tag: 1623721627-211478 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. 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..935814f332a7 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 +# Sometimes an architecture might not be able to support inline instrumentation +# but might be able to support outline instrumentation. This option allows an +# arch to prevent inline and stack instrumentation from being enabled. +# ppc64 turns on virtual memory late in boot, after calling into generic code +# like the device-tree parser, so it uses this in conjuntion with a hook in +# outline mode to avoid invalid access early in boot. +config ARCH_DISABLE_KASAN_INLINE + bool + 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"