Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3279795pxj; Mon, 14 Jun 2021 19:48:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxKSsgGi+1mLQkAgEgYaoijAlZD+5s1SpSOkN3BIZ9Rae9F5ba+/5klAEHSdjExZ5ZCnERx X-Received: by 2002:a17:906:dfd1:: with SMTP id jt17mr18276682ejc.486.1623725327762; Mon, 14 Jun 2021 19:48:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623725327; cv=none; d=google.com; s=arc-20160816; b=huf0kHnZd3AqqSEbnL//NlFMG7AL9e+I5r5w3k7+vGCJRb3ki+r7DKz57nE4E92vwb 8R1S9Bgn7mfsKHfchQ9Vq74PAEImI+E/ByVWNJ2yRUlNI7anwXV4nbfbsdZ4JbkKyNTw e3bXs4CengZ2TRh4MjGrleD9x+c+le9v2h+vL7XlJjewbnidQ+mkGcV0KeLzGEHrku+O vN+qcXZEYyYvIDKpVuhkWPcS42A0Q9ah4LEutK5ffC1PQ+vAugq8m8U18PNdevHV+bjM YUNQXTh0olelotCtdykP9NO6XoyPO040/QvvSC5fOYvVRoFBvUKOw6VrshhYzo2dk6kN opsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=HOnQVo+SWV1H037ZQ/Ye/PGWwO/+/ZmfPhIlu9wOFzQ=; b=XvoqydVnguvMoHWR7/wesJKS/11Mr2NSaIGgNbPYTi4O6VcOOHY2XKqAdrHBv7sNdh LuvXCF63NECLd9xYuCpDER2svs57cKIcMp6volrtgeHdWD2X/VKZzB35B4XSecjlPJEc nuaKjU4Wfbj8o6cI5GVakUV841oWpnEDM2K6NSWiwk7CZpW/WwfPm1SYEWoCvQVCvNFa DUojOCcT7qRF1POCZm+jjBofcxn9fW2R7KdqAprnN2W9dGGGNMWfl0V5k/VafETca7Is kbJTs0wJuuznEWra0weVqlcb74g/caCLyXaPTx8ITpXUpCz7AU0iM1AwvwPUgF1aYH0n xEcw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@axtens.net header.s=google header.b=Pn6LBDzC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i12si991281ejo.503.2021.06.14.19.48.25; Mon, 14 Jun 2021 19:48:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@axtens.net header.s=google header.b=Pn6LBDzC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230141AbhFOCs4 (ORCPT + 99 others); Mon, 14 Jun 2021 22:48:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48880 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230190AbhFOCsz (ORCPT ); Mon, 14 Jun 2021 22:48:55 -0400 Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 69558C061574 for ; Mon, 14 Jun 2021 19:46:51 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id p14so959373ilg.8 for ; Mon, 14 Jun 2021 19:46:51 -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=ce/EyA0wfci4guEYouov8ix/JvSO/jpylBjx3HXNhniKTMkj3wC1AdcohHtkV6wpmV PPPuMcJhbmxIzjQlqkeE0Cc7kOOjuRVaiK5j2xSwbEEvZc5Mdz5cZdqbmYBGrCr81qU9 KTYdFv4xJKk70TvypnYttPxbVx/KYCM0dgf76W1RmGyQmQSHdCwv7T6whYwigSbcYKx2 yFEufTyPSNrqOrXhjvsACF/YXZpLVF2X3kmuANq0ArtP5ZIExMtGTOjLA0lkfJCdWWed XmfHCZYqpKynQ+dog8D5LiBzIUDKM+EvoRJglep5fMOPpecC3tYBwnGdP/rA0QSCytXv AGqw== X-Gm-Message-State: AOAM533zTXQ70nRyh7M7g5cUxjc7amkwJw5xVW3vAOpPZLwo2CXW1H2L UJLfTpt7mCAin2rbbPJ7OC4VdPtwJRHEpg== 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 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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" -- 2.27.0