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.8 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 7A875C43467 for ; Wed, 14 Oct 2020 20:46:46 +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 0C99922248 for ; Wed, 14 Oct 2020 20:46:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="tLORgbI+"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="XHIWX6TP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0C99922248 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=w8jtaCDuXS32HGN2kCvA0Lx3XimJKZyg3S0YCkasf1Q=; b=tLORgbI+XmLMC2wYXtXQp9Fayj i5TE8rZ7Hxky+CDq+Bse57YaPKQchVU4FVX8/EgS4i5mAhYesr8rILr/PF9YkaPGboyw5mqgUlcnb 81KPUTCpnTBqphaG/nVokiaG3t5HTQpDzIWSjs+2rM8K3JpYUQ8o3fXLnW44jVKNfSmvsyMOoOQJG n7w14xX9eh+xmD6QfChEgxH/xWwdoSXXYoCT5a6IB1r1RnIYcGogd26ebq/ur4rZe3ZclnwUaT25s GeA1cqF1y3UeDlLsVWnBfJDEx82LeFbCpoiNPX9rR88vwYZ6lH6anKkka+BHQtjD7CwB5O0WMSo0R o8zFM6vQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSndl-0001bM-2Y; Wed, 14 Oct 2020 20:44:53 +0000 Received: from mail-qv1-xf4a.google.com ([2607:f8b0:4864:20::f4a]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSndi-0001Ze-Hb for linux-arm-kernel@lists.infradead.org; Wed, 14 Oct 2020 20:44:51 +0000 Received: by mail-qv1-xf4a.google.com with SMTP id m11so303252qvt.11 for ; Wed, 14 Oct 2020 13:44:45 -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=Wp6ksUSUbEBH3QFRcUbKn90ZmE0mGR4EaPOxflY/Bhk=; b=XHIWX6TPUFJcGkAyHbWmWYvAO2eoTUguo4tRVo9+s/uBaOM7wucKOo1UnOUyeevkYw ZW6L/ImbWQf1HDVWU1I7EP+YsIxOm5CRxYHiSJDsN7IPEO5KqdenWyJzJsAHQbaQ//dy MbjXRVqE1oG+KlALEYmR2h9SbsySTuWvBPnc9mc9TqQQmIodwB10fqezFmIAGG7qG27c jI6/ynsLEqFTXnvb678mUKa/4ATypgMGNTxnYcZ+qjEeuw4HTQKDUFfc0T3bevZaecso rR2v2yabN6AoS1g6a4EXSSFWcUQAVcm2Y7UavScPQw5h1MatLhgkV8ZEZnycheR4WEn0 kpAg== 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=Wp6ksUSUbEBH3QFRcUbKn90ZmE0mGR4EaPOxflY/Bhk=; b=W8djLQre80G1Y/+KqM7AxX3lBSG3xQK4LjgeI80rWtyn30y/uwM0s3nSSYye2Y3DFU OQeMx6Wm5Pn3eVT5Zfdvc6hStwmQQ0fIPkmYb0bEGLGITahximcwG615q9978u+9ziWi p9+C1D0XevQE3bbUqr1uZ2okfnI/S6FR4fUWhURhNDS8HN6ZRm8o+CT1wW5CClhIdtss IpEb0az8m9JCpeqh0Y52yuiyLYZOdzY+UbBIOl2w2ltP7b+jff5+eqEc8v46DoIboNBq gpNDu7Fwej+lnJkAnyBDBKu9od7axYn0yq8QgC2i3F6JV9MgXXugxt8sZeZ4UfyvFWEg LHEw== X-Gm-Message-State: AOAM532EzAXguMOUAsu4Z8RiwcGK9lThIiWzkWYl/921z0wXvOYfrxLr +DxcDvu3ioUcltBbTss5TfzB6N1pP2TLpJi7 X-Google-Smtp-Source: ABdhPJy0w2DnvpsFk3ItIJc1FaFkjnQTtGD7dHFRkOJ2Z1pc/lhHaiZhAhM/IoqGk5LaY9pnhlyLDnPQtq6jckck X-Received: from andreyknvl3.muc.corp.google.com ([2a00:79e0:15:13:7220:84ff:fe09:7e9d]) (user=andreyknvl job=sendgmr) by 2002:ad4:5747:: with SMTP id q7mr1451102qvx.0.1602708284222; Wed, 14 Oct 2020 13:44:44 -0700 (PDT) Date: Wed, 14 Oct 2020 22:44:28 +0200 Message-Id: Mime-Version: 1.0 X-Mailer: git-send-email 2.28.0.1011.ga647a8990f-goog Subject: [PATCH RFC 0/8] 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 , Evgenii Stepanov X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201014_164450_603742_32052BFD X-CRM114-Status: GOOD ( 22.15 ) 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 , Andrey Konovalov , Kevin Brodsky , linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, Andrey Ryabinin , Andrew Morton , linux-arm-kernel@lists.infradead.org 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 (see particular TODOs in the last patch), and I haven't performed any benchmarking yet, 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 last patch of this series adds a new boot time parameter called kasan_mode, which can have the following values: - "kasan_mode=on" - only production features - "kasan_mode=debug" - all debug features - "kasan_mode=off" - no checks at all (not implemented yet) Currently outlined differences between "on" and "debug": - "on" doesn't keep track of alloc/free stacks, and therefore doesn't require the additional memory to store those - "on" uses asyncronous tag checking (not implemented yet) === Questions The intention with this kind of a high level switch is to hide the implementation details. Arguably, we could add multiple switches that allow to separately control each KASAN or MTE feature, but I'm not sure there's much value in that. Does this make sense? Any preference regarding the name of the parameter and its values? What should be the default when the parameter is not specified? I would argue that it should be "debug" (for hardware that supports MTE, otherwise "off"), as it's the implied default for all other KASAN modes. Should we somehow control whether to panic the kernel on a tag fault? Another boot time parameter perhaps? Any ideas as to how properly estimate the slowdown? As there's no MTE-enabled hardware yet, the only way to test these patches is use an emulator (like QEMU). The delay that is added by the emulator (for setting and checking the tags) is different from the hardware delay, and this skews the results. A question to KASAN maintainers: what would be the best way to support the "off" mode? I see two potential approaches: add a check into each kasan callback (easier to implement, but we still call kasan callbacks, even though they immediately return), or add inline header wrappers that do the same. === Notes This patchset is available here: https://github.com/xairy/linux/tree/up-prod-mte-rfc1 and on Gerrit here: https://linux-review.googlesource.com/c/linux/kernel/git/torvalds/linux/+/3460 This patchset is based on v5 of "kasan: add hardware tag-based mode for arm64" patchset [1]. 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 Andrey Konovalov (8): kasan: simplify quarantine_put call kasan: rename get_alloc/free_info kasan: introduce set_alloc_info kasan: unpoison stack only with CONFIG_KASAN_STACK kasan: mark kasan_init_tags as __init kasan, arm64: move initialization message arm64: kasan: Add system_supports_tags helper kasan: add and integrate kasan_mode boot param arch/arm64/include/asm/memory.h | 1 + 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 | 14 ++--- mm/kasan/common.c | 90 ++++++++++++++++++-------------- mm/kasan/generic.c | 18 ++++--- mm/kasan/hw_tags.c | 63 ++++++++++++++++++++-- mm/kasan/kasan.h | 25 ++++++--- mm/kasan/quarantine.c | 5 +- mm/kasan/report.c | 22 +++++--- mm/kasan/report_sw_tags.c | 2 +- mm/kasan/sw_tags.c | 14 +++-- 13 files changed, 182 insertions(+), 79 deletions(-) -- 2.28.0.1011.ga647a8990f-goog _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel