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 4CD2FC388F7 for ; Thu, 22 Oct 2020 17:00:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BBFBF24630 for ; Thu, 22 Oct 2020 17:00:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="YnO2A44c" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BBFBF24630 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 29B6F6B0068; Thu, 22 Oct 2020 13:00:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 24BE66B006E; Thu, 22 Oct 2020 13:00:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 114A76B0070; Thu, 22 Oct 2020 13:00:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0189.hostedemail.com [216.40.44.189]) by kanga.kvack.org (Postfix) with ESMTP id D87766B0068 for ; Thu, 22 Oct 2020 13:00:56 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 6EECF181AEF0B for ; Thu, 22 Oct 2020 17:00:56 +0000 (UTC) X-FDA: 77400176112.10.linen07_430092827252 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin10.hostedemail.com (Postfix) with ESMTP id 3506716A06B for ; Thu, 22 Oct 2020 17:00:56 +0000 (UTC) X-HE-Tag: linen07_430092827252 X-Filterd-Recvd-Size: 7990 Received: from mail-pf1-f195.google.com (mail-pf1-f195.google.com [209.85.210.195]) by imf25.hostedemail.com (Postfix) with ESMTP for ; Thu, 22 Oct 2020 17:00:55 +0000 (UTC) Received: by mail-pf1-f195.google.com with SMTP id c20so1505385pfr.8 for ; Thu, 22 Oct 2020 10:00:55 -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=C9Aq1WFRNzdLR8UtlVTni3Xh5pWCzbV3aMmYTzeHRyk=; b=YnO2A44cuaSmChU0uMnRd6pi32Jy01cimU6nmFhGtx2wsyKIKUvEFoeSl59skxdqKe OcmG+crA2W2V08HAm6naoonqEw2GZYJsNzd2AF2sxKnn++uh7j4O0LQXYaY+QTfXWcxp a8yZIJCso4Ik9njZLIbA+z+iRR7noHu7GOQa8sp2FXhekPD8cQguitj4Rd8KoA6ft7VA xE1M7hS2hPF3gaPAuCl7VbHFvPzpE1xKk7KVp1RDiB36vdAb31rRT3JgFYOxomoITtI2 fAj79M9kHP7QGQsQw2Sm0gF2zR34RxrzUccA4RbRIXm7XioKUwnys3d2R6PPVa9wfolX liVw== 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=C9Aq1WFRNzdLR8UtlVTni3Xh5pWCzbV3aMmYTzeHRyk=; b=duWeRCqE23AiwsjZwDAVtlLJfdWGJlXBM8xeFYq1gxcYYtuvr8Qx0j4Em1B2XAbmp7 mogKZd5Saa0+E7G+tW2nF5fpU6t4ib8M+0RQe1x05IHU0Ia0kOjTAnLuBwzucs1ojeX0 8JdXhewbtCdxjjhycWedOm30YZ3RRaXow673Jml51/K4HAJ4nP6NzTn7UlaivNeN7hXl cQ7KsqbnN6imcFz+XosUvU3cluIqxPb0kSIMsdDmin/wwl+qAqq4SdJmMaDNwHewm+LH 6ex5O3WSFCwyuDdHREdcwOOlaxGZAVddzoPFXwSzqyi4DWJC53ubnbVx6FlFua149eUI xndw== X-Gm-Message-State: AOAM532eYOHLqzScjZFrG4qS0um6YRtms27tEW8x17IwQeQ9llKrdvpo Hg68plHsl6boObIff9GJnKjGA2wPhzYEpQYOk1glIw== X-Google-Smtp-Source: ABdhPJwIseJokmT+15DzDDxEnbPxtuHJDwDil7DuPbISBzf7KXMs0rivuA2lf05e1BwryEUEpoDbXlieMHevMhiZ9CA= X-Received: by 2002:a63:d456:: with SMTP id i22mr3020892pgj.440.1603386054345; Thu, 22 Oct 2020 10:00:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrey Konovalov Date: Thu, 22 Oct 2020 19:00:43 +0200 Message-ID: Subject: Re: [PATCH RFC v2 00/21] kasan: hardware tag-based mode for production use on arm64 To: Dmitry Vyukov 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 5:16 PM Dmitry Vyukov wrote: > > 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. FTR, this only accounts for slab memory overhead that comes from redzones that store stack ids. There's also page_alloc overhead from the stacks themselves, which I didn't measure yet. > > > > === 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. Perfect! I realized that I actually forgot to think about the default values when no boot params are specified, I'll fix this in the next version. > > 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? I'll explore this. > 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). Sounds reasonable. Thanks!