From mboxrd@z Thu Jan 1 00:00:00 1970 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=-12.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=unavailable 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 00D54C43463 for ; Fri, 18 Sep 2020 15:08:12 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E2AFF23888 for ; Fri, 18 Sep 2020 15:08:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="RJ/7SdO9"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="QngUTfXW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E2AFF23888 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=84Ku9Rxud/N45Z01pwo6bOYhznI1FmDg8AbzdtNpIaI=; b=RJ/7SdO9D1tN9CyCcTIZ7WsDK xpS940NOjQXpn7Lmvsz2q0GtN4oHehXCUCmsGN7rlUWggDY/B0Aw7sTdYeoUAa4QgwOVzmnOmfihw LQ90ONlekMdBth1XyqrzcPoO9+QX6Fg06QlS4leNZVjWOFkbEmRJx/fTsUo5DaEGHQkT7wGB8z5ig kISehR0YQMEdodBn3Tlnot2f8+MAhM/OyrQL1YU72Vbc5nUZUT/lzPFFbgN8JDvxllCAjOvWH6ZPl pTFh+U6wVM7S1uC2QiXcXI0QdjfGZR9l79xutzgEBc/6MU8io5R8BRAH6ARj8H7KUREanD06url+v Q2Hsp6GNg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kJHyA-00013Y-Ch; Fri, 18 Sep 2020 15:06:39 +0000 Received: from mail-pf1-x444.google.com ([2607:f8b0:4864:20::444]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kJHy7-00011z-FW for linux-arm-kernel@lists.infradead.org; Fri, 18 Sep 2020 15:06:36 +0000 Received: by mail-pf1-x444.google.com with SMTP id n14so3614799pff.6 for ; Fri, 18 Sep 2020 08:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TokX/cApb7HEDUJUqNTQw5zrxkPkqdM85vur5KC2Xr4=; b=QngUTfXWesbMq8rO+ocht18+krYak4lpZf5vLUJOJg4gYNJ7EHk2UNXACXLWrlot/G bpGsGlVN6DU9k5wKgdIWkfCFA7ESAR19tM7NiS8LZ+o7KAN2FiUTB4rwsDsEAzRk7YOo +0qRRyorJUpDIX65+zAPvOUugM7YqbjggjxA/YDwYyc1XKfmBgHRjcqdyTBYHIfw482B U5+cuowsWjWnTWks6fwusSgk0mZSLPFDZVyTGSSMd+Yd9EqzFlJDeDPn8bUC9RLsLc6R 7UwJPvmAdBcCZ2C9HnHTpMx5AuVwjq+q9vtwNTt+3UT0DFgeMhjUQ7P56gtU0eSt0quP uQtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TokX/cApb7HEDUJUqNTQw5zrxkPkqdM85vur5KC2Xr4=; b=Dxs+fjeTybcmNKmrZkb/GWWOjVuD3661qTsAnfitqor8Kn44ckMmXhxSz0mGkHE2+p WJpAgdSWpwHdiRNAnrIKJrt7r89KCrU/hioD8FZ/kaAyFwe0nm37XY3ucM3sOoPUVebk TLo8UVxMvUP0aYdMxJf4ZjxxksUuNrfsKINm/XnnFVdxM1yKljhFBkFpMdhIUHel7x0K SEHM9g8yER76Fp2ZtRCK0So//KN8W8nJqgEPhT1040Xha90n+dE2H85zrYRRNCD+9zmY KX7yRT4Q9cTTPf0kxoUJadpXU7R1fAOALTyYWzpLsTUBbRDyfxaJD+x8tdmt/h9rK+wZ XDjA== X-Gm-Message-State: AOAM533icSMxY5cpRr2aKzcc7UA6LKjYt5EB4Mcg+RbNgnYtvk9DdMYe ZsCnP1gJeOFoUsEW5QX1rTPgCXjjw9v3Gd+RxzoH8A== X-Google-Smtp-Source: ABdhPJzWTmWqIO4o1NHRtchE/7VfeSDWkcclq8WfIDQdB/vbq0h+ZsNZRaTzGOSEtWfEOLd6NZ7xvgrJQeIxj7FvqYk= X-Received: by 2002:a62:1d51:0:b029:13e:d13d:a0fc with SMTP id d78-20020a621d510000b029013ed13da0fcmr33038595pfd.24.1600441592809; Fri, 18 Sep 2020 08:06:32 -0700 (PDT) MIME-Version: 1.0 References: <329ece34759c5208ae32a126dc5c978695ab1776.1600204505.git.andreyknvl@google.com> <20200918123249.GC2384246@elver.google.com> In-Reply-To: <20200918123249.GC2384246@elver.google.com> From: Andrey Konovalov Date: Fri, 18 Sep 2020 17:06:21 +0200 Message-ID: Subject: Re: [PATCH v2 21/37] kasan: introduce CONFIG_KASAN_HW_TAGS To: Marco Elver X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200918_110635_563501_2CDA017F X-CRM114-Status: GOOD ( 35.58 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linux ARM , Branislav Rankov , Elena Petrova , Catalin Marinas , Kevin Brodsky , Will Deacon , LKML , kasan-dev , Linux Memory Management List , Alexander Potapenko , Evgenii Stepanov , Andrey Ryabinin , Andrew Morton , Vincenzo Frascino , Dmitry Vyukov Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Sep 18, 2020 at 2:32 PM Marco Elver wrote: > > On Tue, Sep 15, 2020 at 11:16PM +0200, Andrey Konovalov wrote: > > This patch adds a configuration option for a new KASAN mode called > > hardware tag-based KASAN. This mode uses the memory tagging approach > > like the software tag-based mode, but relies on arm64 Memory Tagging > > Extension feature for tag management and access checking. > > > > Signed-off-by: Andrey Konovalov > > Signed-off-by: Vincenzo Frascino > > --- > > Change-Id: I246c2def9fffa6563278db1bddfbe742ca7bdefe > > --- > > lib/Kconfig.kasan | 56 +++++++++++++++++++++++++++++++++-------------- > > 1 file changed, 39 insertions(+), 17 deletions(-) > > > > diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan > > index b4cf6c519d71..17c9ecfaecb9 100644 > > --- a/lib/Kconfig.kasan > > +++ b/lib/Kconfig.kasan > > @@ -6,7 +6,10 @@ config HAVE_ARCH_KASAN > > config HAVE_ARCH_KASAN_SW_TAGS > > bool > > > > -config HAVE_ARCH_KASAN_VMALLOC > > +config HAVE_ARCH_KASAN_HW_TAGS > > + bool > > + > > +config HAVE_ARCH_KASAN_VMALLOC > > bool > > > > config CC_HAS_KASAN_GENERIC > > @@ -20,10 +23,11 @@ config CC_HAS_WORKING_NOSANITIZE_ADDRESS > > > > menuconfig KASAN > > bool "KASAN: runtime memory debugger" > > - depends on (HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC) || \ > > - (HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS) > > + depends on (((HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC) || \ > > + (HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS)) && \ > > + CC_HAS_WORKING_NOSANITIZE_ADDRESS) || \ > > + HAVE_ARCH_KASAN_HW_TAGS > > depends on (SLUB && SYSFS) || (SLAB && !DEBUG_SLAB) > > - depends on CC_HAS_WORKING_NOSANITIZE_ADDRESS > > select SLUB_DEBUG if SLUB > > Is SLUB_DEBUG necessary with HW_TAGS? I'll check and drop it if it's unnecessary. > > select CONSTRUCTORS > > select STACKDEPOT > > @@ -38,13 +42,18 @@ choice > > prompt "KASAN mode" > > default KASAN_GENERIC > > help > > - KASAN has two modes: generic KASAN (similar to userspace ASan, > > - x86_64/arm64/xtensa, enabled with CONFIG_KASAN_GENERIC) and > > - software tag-based KASAN (a version based on software memory > > - tagging, arm64 only, similar to userspace HWASan, enabled with > > - CONFIG_KASAN_SW_TAGS). > > + KASAN has three modes: > > + 1. generic KASAN (similar to userspace ASan, > > + x86_64/arm64/xtensa, enabled with CONFIG_KASAN_GENERIC), > > + 2. software tag-based KASAN (arm64 only, based on software > > + memory tagging (similar to userspace HWASan), enabled with > > + CONFIG_KASAN_SW_TAGS), and > > + 3. hardware tag-based KASAN (arm64 only, based on hardware > > + memory tagging, enabled with CONFIG_KASAN_HW_TAGS). > > > > - Both generic and tag-based KASAN are strictly debugging features. > > + All KASAN modes are strictly debugging features. > > + > > + For better error detection enable CONFIG_STACKTRACE. > > I don't think CONFIG_STACKTRACE improves error detection, right? It only > makes the reports more readable Yes, will fix. > > > > config KASAN_GENERIC > > bool "Generic mode" > > @@ -61,8 +70,6 @@ config KASAN_GENERIC > > and introduces an overhead of ~x1.5 for the rest of the allocations. > > The performance slowdown is ~x3. > > > > - For better error detection enable CONFIG_STACKTRACE. > > - > > Currently CONFIG_KASAN_GENERIC doesn't work with CONFIG_DEBUG_SLAB > > (the resulting kernel does not boot). > > > > @@ -72,9 +79,11 @@ config KASAN_SW_TAGS > > help > > Enables software tag-based KASAN mode. > > > > - This mode requires Top Byte Ignore support by the CPU and therefore > > - is only supported for arm64. This mode requires Clang version 7.0.0 > > - or later. > > + This mode require software memory tagging support in the form of > > + HWASan-like compiler instrumentation. > > + > > + Currently this mode is only implemented for arm64 CPUs and relies on > > + Top Byte Ignore. This mode requires Clang version 7.0.0 or later. > > > > This mode consumes about 1/16th of available memory at kernel start > > and introduces an overhead of ~20% for the rest of the allocations. > > @@ -82,15 +91,27 @@ config KASAN_SW_TAGS > > casting and comparison, as it embeds tags into the top byte of each > > pointer. > > > > - For better error detection enable CONFIG_STACKTRACE. > > - > > Currently CONFIG_KASAN_SW_TAGS doesn't work with CONFIG_DEBUG_SLAB > > (the resulting kernel does not boot). > > > > +config KASAN_HW_TAGS > > + bool "Hardware tag-based mode" > > + depends on HAVE_ARCH_KASAN_HW_TAGS > > + depends on SLUB > > + help > > + Enables hardware tag-based KASAN mode. > > + > > + This mode requires hardware memory tagging support, and can be used > > + by any architecture that provides it. > > + > > + Currently this mode is only implemented for arm64 CPUs starting from > > + ARMv8.5 and relies on Memory Tagging Extension and Top Byte Ignore. > > + > > endchoice > > > > choice > > prompt "Instrumentation type" > > + depends on KASAN_GENERIC || KASAN_SW_TAGS > > default KASAN_OUTLINE > > > > config KASAN_OUTLINE > > @@ -114,6 +135,7 @@ endchoice > > > > config KASAN_STACK_ENABLE > > bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST > > + depends on KASAN_GENERIC || KASAN_SW_TAGS > > help > > The LLVM stack address sanitizer has a know problem that > > causes excessive stack usage in a lot of functions, see > > How about something like the below change (introduce KASAN_INSTRUMENTED > Kconfig var) to avoid the repeated "KASAN_GENERIC || KASAN_SW_TAGS". > This could then also be used in the various .c/.h files (and make some > of the code more readable hopefully). I tried doing that initially, but it didn't really look good. The reason is that we actually have two properties that are currently common for the software modes, but aren't actually tied to each other: instrumentation and shadow memory. Therefore we will end up with two new configs: KASAN_INSTRUMENTED and KASAN_USES_SHADOW (or something), and things get quite confusing. I think it's better to keep KASAN_GENERIC || KASAN_SW_TAGS everywhere. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel