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=-3.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 2EE44C388F7 for ; Thu, 22 Oct 2020 15:17:30 +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 6A3EC20882 for ; Thu, 22 Oct 2020 15:17:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="KivX9ij1"; dkim=fail reason="signature verification failed" (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 6A3EC20882 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=4l9rHxKVhjOwj2MglleVZ2tOhT6qY15zY3koXUwPNP4=; b=KivX9ij173LLeY8Suinw+9D4S jWP+xmyghnMEKzOKQh/IiTBlfrnabZOV/VNAK+hIICKcqXpZ2hvqUVxWL4X5Et55auz5LYrzQZR8K qdplct12Hpq5ahWtRev5KWLZ1pEZHQzo3ognQ51L4OaMexC22qKBVVFMMosfbBIq7mFAzDDypXcqs /55bjBazqpD3vA20nNduSfE/Ee6O6uJ9f91r3eW0zBq3lZRGDlql4Tdhwb1Xmepr6kKYXBC4kK5Vz PHlelzNprB8hIF5FY0JT+dW1BjgFKvGNO4N5qC2ol7CM25IW9ajjSFxfBxpVKb9s18ZrXK5cVFzhq ZUPzrvBzw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVcK4-00066w-JQ; Thu, 22 Oct 2020 15:16:12 +0000 Received: from mail-qt1-x844.google.com ([2607:f8b0:4864:20::844]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVcK1-000662-Rz for linux-arm-kernel@lists.infradead.org; Thu, 22 Oct 2020 15:16:10 +0000 Received: by mail-qt1-x844.google.com with SMTP id h12so1297763qtu.1 for ; Thu, 22 Oct 2020 08:16:08 -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=ExSbvqTE6hxG+olBIYVTHzmLs4JL6NB53JgYzoePWlLD3h/EIpFrO0J7ZGIHQMOyav /9Iv0OwVx5v0VpNuIZveL6hTgotVAmGKy1L3pUYPRysNHsmNpCn7QUewy0c/G8AK8/ZL oQ0BRtUR/kh3S7YdAYDbSigKzdKEVeeOdAey6faPBHHJ6Sno+dOoFC6VibNEMMjnIpUW 7VhDHWbYbpPzcKftAsp8DTU0iOFsy5UJpwcjxkEd3JTbo7qG7cLA7tmbYVWeWGJ33duI 3T9wsXbS/3AlhMxC5CV9tVxSHgmLJrtlc2zWlPgotFMiWHxZD+n2vwx2rUv0v2RTsnLQ 52ag== X-Gm-Message-State: AOAM532LVofEjrg+MFZyMzw11DULvFF7xol4RzD1VhQwzPCPfL5Rs/Sw yx1nPuoQK75dXBnVb83TrIaOiP2PPCn5ihtNS8v0MA== 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201022_111609_915629_630B1151 X-CRM114-Status: GOOD ( 29.62 ) 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: Marco Elver , Elena Petrova , Linux-MM , Catalin Marinas , Kevin Brodsky , Will Deacon , Branislav Rankov , kasan-dev , LKML , Kostya Serebryany , Alexander Potapenko , Linux ARM , Serban Constantinescu , Andrey Ryabinin , Andrew Morton , Vincenzo Frascino , Peter Collingbourne , Evgenii Stepanov 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 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). _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel