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.5 required=3.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham 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 1E6E2C433E7 for ; Wed, 14 Oct 2020 20:44:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5D47A2224D for ; Wed, 14 Oct 2020 20:44:47 +0000 (UTC) Authentication-Results: mail.kernel.org; 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 5D47A2224D 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 84933900002; Wed, 14 Oct 2020 16:44:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7FA4F6B0062; Wed, 14 Oct 2020 16:44:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6E8AD900002; Wed, 14 Oct 2020 16:44:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0058.hostedemail.com [216.40.44.58]) by kanga.kvack.org (Postfix) with ESMTP id 416F06B005D for ; Wed, 14 Oct 2020 16:44:46 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id CA5DD1EE6 for ; Wed, 14 Oct 2020 20:44:45 +0000 (UTC) X-FDA: 77371709730.17.fang38_3e156102720e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin17.hostedemail.com (Postfix) with ESMTP id AF0C1180D0180 for ; Wed, 14 Oct 2020 20:44:45 +0000 (UTC) X-HE-Tag: fang38_3e156102720e X-Filterd-Recvd-Size: 8096 Received: from mail-qk1-f201.google.com (mail-qk1-f201.google.com [209.85.222.201]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Wed, 14 Oct 2020 20:44:45 +0000 (UTC) Received: by mail-qk1-f201.google.com with SMTP id v190so566051qki.21 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=aj4SoOqrtjIcS0c0PtIV4PPe6nst2c6/66tSWH4T/e2phcUYRzfvITdbx817w7jh3n Fd4Wp0isK3aXUB8BNbeiNvYA9AGKVzpMlmukIhTFd4swFUzr0J246hSbXMPYE4H+Qdpw TC4uWZfFUDeIxwPVs956l7ThAFy31pMkbEy129pOANSqVIH5W5QExraoUlECvPVsyp6+ e4B8mjHGdWFXduvyoN27BvAAOcypkZO7/MttcWMZYzS3nXyDS1fJyeDHLL8QEkfgtB3f L8CBFSj+CKOKlFgTI8S3mXEvaPlHs1s7J3T07SWx4MpPjHdl065BNBfvFFis+KyLEfOF qehQ== X-Gm-Message-State: AOAM532F82WxKytoLM9Z3W/UzxaqFbNwlvdgu47GhctGbtev8sS9XhD2 y+QK4tsP2W7+HUlCCwcYzlFHomKkNfl+Qrg7 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 Cc: Andrey Ryabinin , Elena Petrova , Branislav Rankov , Kevin Brodsky , Andrew Morton , kasan-dev@googlegroups.com, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrey Konovalov 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: 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