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 CFF13C56201 for ; Thu, 22 Oct 2020 17:03:05 +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 5841D24630 for ; Thu, 22 Oct 2020 17:03:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="3LJCjsPd"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="YnO2A44c" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5841D24630 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=uS9P/CZjU2eyI2adSRFQDk8dViJqnZ9zOWoI0mfjUSQ=; b=3LJCjsPdY+J4o9BbOnW38z419 cg1p+6YWUa16d0z69gpg/GG1A8k5kI/t5it4gOzK/XIAf7CLjGzW1tQL63Y/wLZdwzZcuPGnExqHS EMgWJZtZhEbsSPgzEc4jHiW4XknMZ3i227SHGFLnqhWHQZfMNLLz6ZX0m/u/CjBUelGGOSL6QDus1 yKMerox3FY/r0ZqefM+4VFVpapGkOaTckcOHR5d4KoKskmc9axjMS8w1vVtrxGSJ+BNH33HK0LtZu sjgsGQgFWiWa/bQysHyXcoPY7fyZKZgHS1qVg2OcqwRKurYCFE6UbS5KS91qgQVg35h/NhLnkrj0a vKCxnJ3pw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVdxV-00058l-SZ; Thu, 22 Oct 2020 17:01:02 +0000 Received: from mail-pg1-x541.google.com ([2607:f8b0:4864:20::541]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVdxS-00056j-Fl for linux-arm-kernel@lists.infradead.org; Thu, 22 Oct 2020 17:00:59 +0000 Received: by mail-pg1-x541.google.com with SMTP id n9so1281158pgt.8 for ; Thu, 22 Oct 2020 10:00:56 -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=iNU7KCehaqtLyvG6rAURBucaTP8P4APjRB2NK/AEWc3Un9xjn0B/WVjW9gX10PSOmN Rn2Z4kqCt6EEf/9FHisK7yua9hAIxjL0ZWR3kM+weHOx+xvGRCOGZtjRxBO+LHrJv853 nmOmSa4XVxgqqyaqfGjOj1QLBCUc5vLwcnoz5VmrVDrzL9lcJw0O3dCy5dBz40tk+/1H 4UisuF15woujPdUkILZwWyVOwqNQIyFYbUaWdqWKIAq/WW/+UjYPrQDn+ghid1Bly6l1 An0hGddDOEtpLYiN52mJ2V4RrMif/CHKRfBHPbQVNMLnOGi9mSb7I0jgXawuEdXP4JKX VX/g== X-Gm-Message-State: AOAM532/eePMg2G2pR8593G67ddmZjlei9VrNuv2xBZoXC0cmHODfhg5 MxpQ/gyAPI9N/EDfyj7OpGgTiqLF+dVC6E8AGzRt6A== 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201022_130058_535831_91665AA3 X-CRM114-Status: GOOD ( 35.16 ) 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 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! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel