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=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no 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 AF15AC388F7 for ; Thu, 22 Oct 2020 15:16:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EB49C2463D for ; Thu, 22 Oct 2020 15:16:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="pu4/oIE9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EB49C2463D 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 1B4936B0070; Thu, 22 Oct 2020 11:16:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1673B6B0074; Thu, 22 Oct 2020 11:16:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 02E0D6B0075; Thu, 22 Oct 2020 11:16:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0214.hostedemail.com [216.40.44.214]) by kanga.kvack.org (Postfix) with ESMTP id CA0806B0070 for ; Thu, 22 Oct 2020 11:16:08 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 679388A8385B for ; Thu, 22 Oct 2020 15:16:08 +0000 (UTC) X-FDA: 77399912016.22.drug13_1004f2927251 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id 434E018038E67 for ; Thu, 22 Oct 2020 15:16:08 +0000 (UTC) X-HE-Tag: drug13_1004f2927251 X-Filterd-Recvd-Size: 7244 Received: from mail-qt1-f195.google.com (mail-qt1-f195.google.com [209.85.160.195]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Thu, 22 Oct 2020 15:16:07 +0000 (UTC) Received: by mail-qt1-f195.google.com with SMTP id h19so1286108qtq.4 for ; Thu, 22 Oct 2020 08:16:07 -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=Z3vmtV0NaowwAl/bkuJPmHs13M06Kmq+h1vxwA4hLas=; b=pu4/oIE96b9WepM1KyYgDHEbBJpHXDkiB0Rc3gA4iHoiWv7uqBRDM2rNU71uBrXzIK z/RSgcF+IqGFQwlvjRUdhEAi1RWf6YDVM2IS/E22uZQAnB4ixbJjgZMkedtOl9JV6QHM TbuewAXGqlRIvn12XGaxHRRYFBQNSPA9wEY+VGn83227qfjQQMX9uycQ5HrEHdHoddCu Pvfdyy11QRd6fWp8M5j38eFs7rcdyALz4fKr1GPWpePcfi0+LDOIbA3IGOuOF40dNCMo 3T+HGTAiLSB8NNiB7TVtY9OrtlNyWvZGktJ2QlqtrNTMh1DxJjjyIRUSj7xlracCmUOo y40g== 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=Z3vmtV0NaowwAl/bkuJPmHs13M06Kmq+h1vxwA4hLas=; b=MfmG2LwPERFHCqQTpyGOXdBMfebTsUNJQaKl2PV5KKXtzf0QLQWQNejy5MVL2fPqxA pAzbQBkewjR7FMFuOAxhJtKE8VfD8MqXBA7Sq5OAObRs+GlqVaUcbqzUNgaX3uXiz8U/ fgaafubyYvWRh8e2YwZ5vt779bAdvStLTquKuhE1n4iyFmUuQTkjLhsEtRI+NGdUwPX/ zDC6Pg8doKONeJaBP3tPPJkK4Uva24hVEmeqoHW9Sp8GkzTP4iQ6KXYl77aquyc6zzY/ RgPWTp6zqYB+JbzRK28IR39cZHsZSqJKuFicQs9FXccxZy+w/4nF66mc+D4DNrYY78PU cm+g== X-Gm-Message-State: AOAM530e4M4Bzow5EnjpNjNOiYb1DwIODjwmwRPF9lJzSLlvU112laqE i+s0uyrDOejWxQaEBHN244ATb6mKnQPoh1SXClkCEA== X-Google-Smtp-Source: ABdhPJxuQ/BA6vpJQzxhrqMGyXaPlsQefVCsoiVd55h1woFQfeiMP0sUtRl8Gzy2ahMruP98DbRdMsq8wSMVueYCGQ8= X-Received: by 2002:ac8:928:: with SMTP id t37mr2588192qth.67.1603379766837; Thu, 22 Oct 2020 08:16:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dmitry Vyukov Date: Thu, 22 Oct 2020 17:15:55 +0200 Message-ID: Subject: Re: [PATCH RFC v2 00/21] kasan: hardware tag-based mode for production use on arm64 To: Andrey Konovalov Cc: Catalin Marinas , Will Deacon , Vincenzo Frascino , Alexander Potapenko , Marco Elver , Evgenii Stepanov , Kostya Serebryany , Peter Collingbourne , Serban Constantinescu , Andrey Ryabinin , Elena Petrova , Branislav Rankov , Kevin Brodsky , Andrew Morton , kasan-dev , Linux ARM , Linux-MM , 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 Thu, Oct 22, 2020 at 3:19 PM Andrey Konovalov wrote: > > This patchset is not complete (hence sending as RFC), but I would like to > start the discussion now and hear people's opinions regarding the > questions mentioned below. > > === Overview > > This patchset adopts the existing hardware tag-based KASAN mode [1] for > use in production as a memory corruption mitigation. Hardware tag-based > KASAN relies on arm64 Memory Tagging Extension (MTE) [2] to perform memory > and pointer tagging. Please see [3] and [4] for detailed analysis of how > MTE helps to fight memory safety problems. > > The current plan is reuse CONFIG_KASAN_HW_TAGS for production, but add a > boot time switch, that allows to choose between a debugging mode, that > includes all KASAN features as they are, and a production mode, that only > includes the essentials like tag checking. > > It is essential that switching between these modes doesn't require > rebuilding the kernel with different configs, as this is required by the > Android GKI initiative [5]. > > The patch titled "kasan: add and integrate kasan boot parameters" of this > series adds a few new boot parameters: > > kasan.mode allows choosing one of main three modes: > > - kasan.mode=off - no checks at all > - kasan.mode=prod - only essential production features > - kasan.mode=full - all features > > Those mode configs provide default values for three more internal configs > listed below. However it's also possible to override the default values > by providing: > > - kasan.stack=off/on - enable stacks collection > (default: on for mode=full, otherwise off) > - kasan.trap=async/sync - use async or sync MTE mode > (default: sync for mode=full, otherwise async) > - kasan.fault=report/panic - only report MTE fault or also panic > (default: report) > > === Benchmarks > > For now I've only performed a few simple benchmarks such as measuring > kernel boot time and slab memory usage after boot. The benchmarks were > performed in QEMU and the results below exclude the slowdown caused by > QEMU memory tagging emulation (as it's different from the slowdown that > will be introduced by hardware and therefore irrelevant). > > KASAN_HW_TAGS=y + kasan.mode=off introduces no performance or memory > impact compared to KASAN_HW_TAGS=n. > > kasan.mode=prod (without executing the tagging instructions) introduces > 7% of both performace and memory impact compared to kasan.mode=off. > Note, that 4% of performance and all 7% of memory impact are caused by the > fact that enabling KASAN essentially results in CONFIG_SLAB_MERGE_DEFAULT > being disabled. > > Recommended Android config has CONFIG_SLAB_MERGE_DEFAULT disabled (I assume > for security reasons), but Pixel 4 has it enabled. It's arguable, whether > "disabling" CONFIG_SLAB_MERGE_DEFAULT introduces any security benefit on > top of MTE. Without MTE it makes exploiting some heap corruption harder. > With MTE it will only make it harder provided that the attacker is able to > predict allocation tags. > > kasan.mode=full has 40% performance and 30% memory impact over > kasan.mode=prod. Both come from alloc/free stack collection. > > === Questions > > Any concerns about the boot parameters? For boot parameters I think we are now "safe" in the sense that we provide maximum possible flexibility and can defer any actual decisions. > Should we try to deal with CONFIG_SLAB_MERGE_DEFAULT-like behavor mentioned > above? How hard it is to allow KASAN with CONFIG_SLAB_MERGE_DEFAULT? Are there any principal conflicts? The numbers you provided look quite substantial (on a par of what MTE itself may introduce). So I would assume if a vendor does not have CONFIG_SLAB_MERGE_DEFAULT disabled, it may not want to disable it because of MTE (effectively doubles overhead).