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=-17.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 1797FC43464 for ; Fri, 18 Sep 2020 15:06:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1927020874 for ; Fri, 18 Sep 2020 15:06:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="QngUTfXW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1927020874 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 70A018E0001; Fri, 18 Sep 2020 11:06:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 693BE6B0071; Fri, 18 Sep 2020 11:06:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 534968E0001; Fri, 18 Sep 2020 11:06:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0146.hostedemail.com [216.40.44.146]) by kanga.kvack.org (Postfix) with ESMTP id 355C16B0070 for ; Fri, 18 Sep 2020 11:06:35 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E57638249980 for ; Fri, 18 Sep 2020 15:06:34 +0000 (UTC) X-FDA: 77276508708.05.wall51_24038d62712c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id BF8131802D516 for ; Fri, 18 Sep 2020 15:06:34 +0000 (UTC) X-HE-Tag: wall51_24038d62712c X-Filterd-Recvd-Size: 10082 Received: from mail-pf1-f195.google.com (mail-pf1-f195.google.com [209.85.210.195]) by imf46.hostedemail.com (Postfix) with ESMTP for ; Fri, 18 Sep 2020 15:06:34 +0000 (UTC) Received: by mail-pf1-f195.google.com with SMTP id f18so3609483pfa.10 for ; Fri, 18 Sep 2020 08:06:33 -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=CcxDvBomLU6cWWlR3KzLfC1JjW4Jk1/TENUlWN055Ys8DINVtTQK9JgbiO/AyuyMp9 Qne/FLT9LRI1sQ0jUFi9xbWfoUyrk4BgrE0K1NvHX+CdxRuQmpf7UcYo6aE1AfVqb0// +gn545kxT2uKWGkx9+lreFK1LS7W+pzWDm1oDcAOKT0BYdFTFITzGWxbtxZTGgM7VeWl V3EQuCN+yDkSoB+LbHUgNcTGgE/30/JOuNxc4e0su6QA4vDtnx0shF0HPUtvYdS54Kz6 dyTzKYuKmyHwZv0zVz6O6QJQrd6P2znm2s5i0MINnYDP7CW77jxv1DZ6OX3azOda7byw nHig== X-Gm-Message-State: AOAM531EfAGtf7txxfxRMg7h2VeWUUrnXraByUFIL+fl4lNW65ImQ4Pm Yl47TrYOMabY+CYmBfM3BLKiRER5WYNRNzp6cnk+LQ== 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 Cc: Dmitry Vyukov , Vincenzo Frascino , Catalin Marinas , kasan-dev , Andrey Ryabinin , Alexander Potapenko , Evgenii Stepanov , Elena Petrova , Branislav Rankov , Kevin Brodsky , Will Deacon , Andrew Morton , Linux ARM , Linux Memory Management List , LKML Content-Type: text/plain; charset="UTF-8" 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: 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.