From patchwork Wed Feb 3 11:59:41 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Axtens X-Patchwork-Id: 12064185 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,URIBL_BLOCKED,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 2810FC433E0 for ; Wed, 3 Feb 2021 12:00:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8BD5D64F74 for ; Wed, 3 Feb 2021 12:00:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8BD5D64F74 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 01A9F6B0072; Wed, 3 Feb 2021 07:00:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F358D6B0073; Wed, 3 Feb 2021 07:00:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E716A6B0074; Wed, 3 Feb 2021 07:00:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id D25DE6B0072 for ; Wed, 3 Feb 2021 07:00:00 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 7AEAB1EE6 for ; Wed, 3 Feb 2021 12:00:00 +0000 (UTC) X-FDA: 77776812960.09.thing57_0715557275d3 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin09.hostedemail.com (Postfix) with ESMTP id 5B41F180AD81F for ; Wed, 3 Feb 2021 12:00:00 +0000 (UTC) X-HE-Tag: thing57_0715557275d3 X-Filterd-Recvd-Size: 5006 Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Wed, 3 Feb 2021 11:59:59 +0000 (UTC) Received: by mail-pg1-f177.google.com with SMTP id j2so15561213pgl.0 for ; Wed, 03 Feb 2021 03:59:59 -0800 (PST) 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=FaxU8G6b68GEdEbXS6bZDEyMoHhbuYhFSTBo6L7+8wc=; b=VmzeA/6jTeJHl92Ui+bW8jMnWfBJzOz2tWH7ZG/ltLwUUaY3jql12q4I/LUKW84XrX SPm285KUxoURFjo+ZFPZtM2ObLr6nzqErBg4pInHV8eJKHAdqJtRup8+irCG03feIu97 pmByKUqzPo0Z1/NZpO9hGbdKuv156j4xyd0Ng= 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=FaxU8G6b68GEdEbXS6bZDEyMoHhbuYhFSTBo6L7+8wc=; b=ZXJhcLN/EbeQg/C/g+lMgUWNF8/0Rh1C6TBNDYpC1QLGnRDTLGUCovNhpYE+BiBjo3 tD+PW4m+ayj6QCmn9Iw7urE/BoKt0dEwY3gX/RxJfm+ZZNa+uI+cY02RTP7xwQZR2lIJ KschUyZTHOwPXBD3xBRK3vpPs7Bps1oAAKYPTkm3vfHB/oJ6BeOnWuR/qjIiz/v+HqHj AtAoXafWfOcIp0iU/TXK9vU6ZktJWE59t76lzBi9ebFUbzPYC8M5XjygSzdICi0SNP+E dw4DfUK691wf6jB1/1nwDGc6iNUOKFyilhl06XafJ5IvjX6WGaWlBI8x/ShfX+tgjivH H6TQ== X-Gm-Message-State: AOAM531rOnZ+Sm37Y+L2cZZR0qd2aQCtocosoiLmE3ra1E6pl7xf1IJS aUOi1bWYQPknTXz8/L6PloizcQ== X-Google-Smtp-Source: ABdhPJzJQ+HrkRqBl3GdIZ8HA1RDMTKlHsN8nxwZJJ2++D58biICNAHrnytqbZjJk0+WJgDowTrAZQ== X-Received: by 2002:a62:a204:0:b029:1c3:fb27:16f3 with SMTP id m4-20020a62a2040000b02901c3fb2716f3mr2777075pff.61.1612353599093; Wed, 03 Feb 2021 03:59:59 -0800 (PST) Received: from localhost (2001-44b8-1113-6700-1c59-4eca-f876-fd51.static.ipv6.internode.on.net. [2001:44b8:1113:6700:1c59:4eca:f876:fd51]) by smtp.gmail.com with ESMTPSA id p2sm2491813pgl.19.2021.02.03.03.59.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Feb 2021 03:59:58 -0800 (PST) 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: Daniel Axtens Subject: [PATCH v10 1/6] kasan: allow an architecture to disable inline instrumentation Date: Wed, 3 Feb 2021 22:59:41 +1100 Message-Id: <20210203115946.663273-2-dja@axtens.net> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20210203115946.663273-1-dja@axtens.net> References: <20210203115946.663273-1-dja@axtens.net> MIME-Version: 1.0 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 | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan index cffc2ebbf185..4f4d3fb8733d 100644 --- a/lib/Kconfig.kasan +++ b/lib/Kconfig.kasan @@ -12,6 +12,9 @@ config HAVE_ARCH_KASAN_HW_TAGS config HAVE_ARCH_KASAN_VMALLOC bool +config ARCH_DISABLE_KASAN_INLINE + def_bool n + config CC_HAS_KASAN_GENERIC def_bool $(cc-option, -fsanitize=kernel-address) @@ -130,6 +133,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 +145,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 +159,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"