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.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,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT 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 A8BF2C388F2 for ; Thu, 22 Oct 2020 13:21:54 +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 24987222E9 for ; Thu, 22 Oct 2020 13:21:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="bTi3dRos"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="no5WMYSS" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 24987222E9 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:From:Subject:Mime-Version:Message-Id:Date: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Owner; bh=TLiV/9OCQKGw7FqREZVH1iq8AAV6v2WKA1QIMaOpV8Q=; b=bTi3dRosaw3fTDvY09rdheruRK GYk6vsb4F3m3SivqgKbq69G2lwQAYdjW0AMPoaVTj8/zINgG87GPiZfMgVhQkWALUtkfroyOwpE6e ycyEPU0brz/3ktnUSMmWmYQjp05tr1fZ3JmPTjSu51NWa2B6Hfnxkp4u8/l+CR9N9vbJRhBPu/rBR KTMD5knYWCxG4l5dBSR03RIWqZ8jfUM48L+pzu+OPxsxklxH3eop/aiu9E/DfXv+0WV1wNPGDiDxg IgWG1ZMMTgpOfthQlmRLLOBdw9s1v4ND4mDs4LRG+hl/zvJ7LAgG4tv0qlQHWZrb5RI+OFhtpxDEw 4KaqUD+Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVaV9-0003eH-D1; Thu, 22 Oct 2020 13:19:31 +0000 Received: from mail-ed1-x549.google.com ([2a00:1450:4864:20::549]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVaV5-0003ce-Sh for linux-arm-kernel@lists.infradead.org; Thu, 22 Oct 2020 13:19:29 +0000 Received: by mail-ed1-x549.google.com with SMTP id a15so662653eda.15 for ; Thu, 22 Oct 2020 06:19:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=sender:date:message-id:mime-version:subject:from:to:cc; bh=gP40pqOrjsRuGDtDL77O5g/LDtgANLIwrEsf6Di4U2Q=; b=no5WMYSS4DXICHO7tqynwf3XdAj1MN4/xY09kXfVDaHV+63950L1AyRK4p2r/e8ouC NexlfADE+SImbTA/gzCkhJCD67GZSLVhMXoPf+T5lpLJca+lrhuwoPXPkoDUrLM6x7Md IRkcBhkYG39NxTZrIlLzi/e4h+7OfoJqdaIPwtxPFHM5g1OJ/VuXXbn5bVNa7dzhVZ1j I3YlMKaxdnoJiQn2fdX+9O7N38qifjSrRWZ2eoY9ZncHCJGOOfierwgIoerL623XkhRe dudHtE4sCo5L/DvSNVM3Uzh6UfGJGTSIs3MFuw8BRQBSNoxcDftKcXzYIwb0htm/wwZL ccag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:message-id:mime-version:subject:from :to:cc; bh=gP40pqOrjsRuGDtDL77O5g/LDtgANLIwrEsf6Di4U2Q=; b=KvTxrVIyp2shAF4NTXHE/NabLNqeHWXNvH+Zp9teYUa6KrSjDZH98mbhrUwrvgEJxa 13Q8FQ5fPCjxb2WhZTeHrM3jTTvC20kjxZOox3Mp+kFU/ORHgNPPpmByYTbcoOLgY26i iC/aq5AgXszruiYNGpzS9wDgM10SNM6FcU/IL9bg04TmL+VVlNc6bl/rpZVCoxDmMYZT HpRiOSFf3ZYAgW6QCrLy4LkP9H98faCduapqikXzGs/OL+oHVoEE/zSbcq5gAdYhwzaw 5vcDRiAknbI7Pj3vLp+EbizGdWZUaL6Gp8dZ0JLZTdNdAsQx0eZezW2evsTRa2eVf8bv kBPQ== X-Gm-Message-State: AOAM531heYfDaWCCQSt89Yqt7r/A1G94w9Jr2OOPMop1trF1KewOD7Oh sD1rwkwdTpOexWL+kWbVt6LgDOCTZohd7PFR X-Google-Smtp-Source: ABdhPJzlhaE947vp64h6xieB3QsrudOdETC5dVB+SqwtB18MkZ1wItOTmJk7R3hQ0eqQI84Ro5n+QMwWgmopJlug X-Received: from andreyknvl3.muc.corp.google.com ([2a00:79e0:15:13:7220:84ff:fe09:7e9d]) (user=andreyknvl job=sendgmr) by 2002:aa7:d7d9:: with SMTP id e25mr2166504eds.253.1603372764236; Thu, 22 Oct 2020 06:19:24 -0700 (PDT) Date: Thu, 22 Oct 2020 15:18:52 +0200 Message-Id: Mime-Version: 1.0 X-Mailer: git-send-email 2.29.0.rc1.297.gfa9743e501-goog Subject: [PATCH RFC v2 00/21] kasan: hardware tag-based mode for production use on arm64 From: Andrey Konovalov To: Catalin Marinas , Will Deacon , Vincenzo Frascino , Dmitry Vyukov , Alexander Potapenko , Marco Elver X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201022_091927_959239_3296D695 X-CRM114-Status: GOOD ( 21.09 ) 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: Branislav Rankov , Elena Petrova , linux-mm@kvack.org, Andrey Konovalov , Kevin Brodsky , linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Kostya Serebryany , linux-arm-kernel@lists.infradead.org, Serban Constantinescu , Andrey Ryabinin , Andrew Morton , 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 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? Should we try to deal with CONFIG_SLAB_MERGE_DEFAULT-like behavor mentioned above? === Notes This patchset is available here: https://github.com/xairy/linux/tree/up-prod-mte-rfc2 and on Gerrit here: https://linux-review.googlesource.com/c/linux/kernel/git/torvalds/linux/+/3707 This patchset is based on v5 of "kasan: add hardware tag-based mode for arm64" patchset [1] (along with some fixes). For testing in QEMU hardware tag-based KASAN requires: 1. QEMU built from master [6] (use "-machine virt,mte=on -cpu max" arguments to run). 2. GCC version 10. [1] https://lore.kernel.org/linux-arm-kernel/cover.1602535397.git.andreyknvl@google.com/ [2] https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/enhancing-memory-safety [3] https://arxiv.org/pdf/1802.09517.pdf [4] https://github.com/microsoft/MSRC-Security-Research/blob/master/papers/2020/Security%20analysis%20of%20memory%20tagging.pdf [5] https://source.android.com/devices/architecture/kernel/generic-kernel-image [6] https://github.com/qemu/qemu === History Changes RFCv1->RFCv2: - Rework boot parameters. - Drop __init from empty kasan_init_tags() definition. - Add cpu_supports_mte() helper that can be used during early boot and use it in kasan_init_tags() - Lots of new KASAN optimization commits. Andrey Konovalov (21): kasan: simplify quarantine_put call site kasan: rename get_alloc/free_info kasan: introduce set_alloc_info kasan: unpoison stack only with CONFIG_KASAN_STACK kasan: allow VMAP_STACK for HW_TAGS mode kasan: mark kasan_init_tags as __init kasan, arm64: move initialization message kasan: remove __kasan_unpoison_stack kasan: inline kasan_reset_tag for tag-based modes kasan: inline random_tag for HW_TAGS kasan: inline kasan_poison_memory and check_invalid_free kasan: inline and rename kasan_unpoison_memory arm64: kasan: Add cpu_supports_tags helper kasan: add and integrate kasan boot parameters kasan: check kasan_enabled in annotations kasan: optimize poisoning in kmalloc and krealloc kasan: simplify kasan_poison_kfree kasan: rename kasan_poison_kfree kasan: don't round_up too much kasan: simplify assign_tag and set_tag calls kasan: clarify comment in __kasan_kfree_large arch/Kconfig | 2 +- arch/arm64/include/asm/memory.h | 1 + arch/arm64/include/asm/mte-kasan.h | 6 + arch/arm64/kernel/mte.c | 20 +++ arch/arm64/kernel/sleep.S | 2 +- arch/arm64/mm/kasan_init.c | 3 + arch/x86/kernel/acpi/wakeup_64.S | 2 +- include/linux/kasan.h | 225 ++++++++++++++++++------- include/linux/mm.h | 27 ++- kernel/fork.c | 2 +- mm/kasan/common.c | 256 ++++++++++++++++------------- mm/kasan/generic.c | 19 ++- mm/kasan/hw_tags.c | 182 +++++++++++++++++--- mm/kasan/kasan.h | 102 ++++++++---- mm/kasan/quarantine.c | 5 +- mm/kasan/report.c | 26 ++- mm/kasan/report_sw_tags.c | 2 +- mm/kasan/shadow.c | 1 + mm/kasan/sw_tags.c | 20 ++- mm/mempool.c | 2 +- mm/slab_common.c | 2 +- mm/slub.c | 3 +- 22 files changed, 641 insertions(+), 269 deletions(-) -- 2.29.0.rc1.297.gfa9743e501-goog _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel