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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 09677EB64D7 for ; Tue, 20 Jun 2023 13:56:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 803998D0002; Tue, 20 Jun 2023 09:56:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B3688D0001; Tue, 20 Jun 2023 09:56:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A23E8D0002; Tue, 20 Jun 2023 09:56:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5C3EF8D0001 for ; Tue, 20 Jun 2023 09:56:27 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 33CE841083 for ; Tue, 20 Jun 2023 13:56:27 +0000 (UTC) X-FDA: 80923276014.21.25F2EA5 Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) by imf28.hostedemail.com (Postfix) with ESMTP id F249DC0029 for ; Tue, 20 Jun 2023 13:56:23 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=CnJeqkL3; spf=pass (imf28.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.167.171 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687269384; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Xu/aiaH31TZLMVI9Tp+a0lmhaF9umbZZEeQm47dZ8JI=; b=JA4qYNrM/UZGNsZ2bDFrbo/P34V9PYSiDRoKdLAQZ/pfQemgTq9DXjpkp3bc03DvrItfG2 OyvDaaZ/ywzrJTtDK+rS+vN8l2whU9eWnepCMc4F1rvs2mxWNZYVWvuDKzvIF5PDfOf5iK nHWTgMyy/R2Ebk+XEYm6pNSclfFnX4k= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687269384; a=rsa-sha256; cv=none; b=boBhqaPyA9P3ewq3Dh10L1RkuvqzvN9RdlKDsWpchTy77EbwPPg422cG8z7czivoBhBJIl yQkIro5OVX2AHezr2rc8fh4CDI0X28d5wKiPLOoOHeexbKYNnEd3DjUggYoV8L/LB3+3pg YWcFL/ddQ0w85DKWGV5keBJVAs7xQzw= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=CnJeqkL3; spf=pass (imf28.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.167.171 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-oi1-f171.google.com with SMTP id 5614622812f47-392116b8f31so3312877b6e.2 for ; Tue, 20 Jun 2023 06:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687269383; x=1689861383; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Xu/aiaH31TZLMVI9Tp+a0lmhaF9umbZZEeQm47dZ8JI=; b=CnJeqkL3ZzkSmcdCSOkUt4xDGbdWTfBD9wl0ylaMOlqI2xPnNVZzwO2QZ3QfjpuKBT CbhB2sgp2Fie6iY/IYbZOyYOaY4LO9ZxAT4dCb2CiF0dRB9s6cmP/LId/jxJNi5VQDrd NjVUiWyNZHhQgUIH3ncvvgMHijgrvc1qBHwqf+I8IQip4dQnqUAuY6CP8qLAO8AbZCIx MZ6I5IkWFqLOLxpt1rsGPeqZBQGquBA8eyTl2gzTQoeNHA5iYHCRkyugMwCjSfkSybFB RssckhgYXhNcvjeqi4wQz6OGu1pabVgySO1l3Q4K3L1vAfVkbNSTHe89T/OdwlTkvaOu 5B5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687269383; x=1689861383; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Xu/aiaH31TZLMVI9Tp+a0lmhaF9umbZZEeQm47dZ8JI=; b=MODmKxk5ojkWt/kndnRrWTdXjsI5eDbdL6pNb8aA/450RdGgKBuaJqH7xHhSxxqeSB /nvhcA172LhglYL9LCz15HOLNWmlzOu6L/26Vcu/4HfslbV7tcEd12/RxflEuYpapLvI PKVNKN6Afh9h0Z1f+LTRRW/2Ym7SXo582gIeRNsHD+F2EuOwTKIDIrbXyLWIIyANcRRz hfKV8Hpb7bJ3eUeSQ5ZTZ+6swibXGFZj/uoYwCnlz85L1OxcffnAYyqWYdl8JKTvEhPT vLyGXWTyD6W98ElZrQ/RY/mHrUi7KbNNEWW8ZqoKVrXOgRkWgTBmkfDhVvZd3niXzQ7d w7xA== X-Gm-Message-State: AC+VfDzPTNUeJj2aadYirJUogbouhue+kzj6tRw5mzACxqV4TqhXnVIz NuEH3+khTwVYwZ4de8UNIZZ1uH2a9/DMrTtd36U= X-Google-Smtp-Source: ACHHUZ76Quqktp3zHudolMcMsRYtqnxo/hI1u1UexkjnqkDAG0iaKT+k6idf61xtF/ADg/Dr9l3UsFl/R6wztd8sVOI= X-Received: by 2002:a05:6808:6397:b0:39c:767e:bfc6 with SMTP id ec23-20020a056808639700b0039c767ebfc6mr11697031oib.10.1687269382925; Tue, 20 Jun 2023 06:56:22 -0700 (PDT) MIME-Version: 1.0 References: <20230614095158.1133673-1-elver@google.com> In-Reply-To: From: Andrey Konovalov Date: Tue, 20 Jun 2023 15:56:10 +0200 Message-ID: Subject: Re: [PATCH] kasan: add support for kasan.fault=panic_on_write To: Marco Elver Cc: Andrew Morton , Alexander Potapenko , Dmitry Vyukov , Taras Madan , Aleksandr Nogikh , Andrey Ryabinin , Vincenzo Frascino , Jonathan Corbet , kasan-dev@googlegroups.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Catalin Marinas Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: m1rw5kcz9qaommpd65wbo8s8wxhtbmax X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: F249DC0029 X-Rspam-User: X-HE-Tag: 1687269383-866874 X-HE-Meta: U2FsdGVkX18oE7A1zD1upIHBD3OgH5Lt5NuJbRY/6F+JY3Ngkaa50gKQqtXmys8CKpW8/gH0FZgl9Y1lH46hZckak5J2hfSbeZruiDlJtxutsEH8R/mH1NF45obodJKEf8KHg/eab9cByYOrKv8v3C/qWeP61HS5mVz4u4AOm1mkZd2olT85A3EzX25IQAs6VM5P6T7TJRQDe3zsXGrp6cz094F33xiIHLXac62F51o7oOi9U18PdCbMaNLp/aPi+Jo4GWfNjnD75hm7kQIxwIOKWBBIhbPuzUScoPUlacpLfk9c58yYDjsFUxG1Ca3yaBp2jGMq5TancBYAvqRZXWR5k8xsrK13a3t141QgPvlho2k2czUrF5es2Ra11PjtPeSsPtGiUSeyyoVkclSQxq8TlbQ09s8nE3EGSGPY/uUgDw0GnCrLFv99mRliQ3JiF3ApSB0/Ug8byLfAxdORyE2nDAFGLk0WluV3DAliniWow2TJDNgZ1ERVFlYFh8HZ5moIsT18OKM0lkYpibCzGamJDxwvPgMg0DkyLupkhSv3DRuo2Q92zLmOlG3nxABKUZGSzIGIgrdXKI5Dgt5DpZvWcbqEV2v5i4lXU7DFzzkuMqtiCbix/nagj778fgHf4uugrhJbwckN0/dw8IrBpb293UGWYBdKRCapiIi/QPuclsNA5fJENcj/sWYh7w2gHNr/vd+WJNrhuVmwdElXHUFUaR8+H2t0YJVJilVwvXUhwP4g8YjmmMHP93wTrW3vNMUmujrmXxK0JurrgqLOzAs+pwOznSwmdqS4z+C8kCtboXSZ82vUPcgzNhI/V/sN8a5u3ErPAyHuxwS0KUh7XYFS9W8C9XxzlLwlFAHKzSenWRp5951FU4n3X3aC746ak31OMhxLXg2K22jbx+HQcmOCeMBy1B0ZvTtR/Q8kFr7fsdo4/Lpl9S96EIEOALQnLnbfBJ/KmFCwE3zFiwc NVoJxdGN 5LBBzpujYUgMTPpmNidH6zeJX9aJRzHF0zY/0rmBei+iVFeI1w2RVPpZgrHmtoyXt5NKI49hN05Km9kj2OLGVwzlIN+tpDWV5BCuxQus34HY4CLioKZGNQ6ul3YchJ6J1zYdKroYwLhAPdFgNsCvtkpekisdWPrQCUVoou9j65Z/QQttFl/JXoaq2eSirkuj0b0P8319DkX+E4AQ8qwvL81HSdl+cEOGmlSxA1dolJKpFcHUMo0YKOQ8ilX/Gzm6n8rJIxEaOOYDXMfvxQc8alZj+EsFRAc1Q29th1WvEApn56vEQ7EBni8AIuhYS4IrrL7tkSTwR6O9co9t0Ypt85yQVIqiAzZyU2yUNM63kWtc0kHFvWFkfcNhGMLcBfdqUhTAoCp+E1b3YX73DcTL+bGgsuSH4wb6O6PcDD2SWHAawFOlYbTxLk5PpnEg378plFxnDRWWOqjsptWU7Tx9/oYSzc9U/k9DDVFgUNHaZgrGSxdUjBOIQOQORLx6oFY2l1HY0A4sLCcWE/N7fKKEa+87ImPQ9ibKVQR1C2lqzumnAjfs= 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 Tue, Jun 20, 2023 at 1:51=E2=80=AFPM Marco Elver wrot= e: > > > Ah, right. I did a quick google to check when I was writing the > > response and found this: https://lwn.net/Articles/882963/. But looks > > like that cover letter is wrong and the documentation is right. I > > wonder what the point of the asymmetric mode is then. > > Maybe not as strong, but asymm mode makes sense from a microarch point > of view, where writes are always committed into a store buffer, but > reads can only commit when the data (incl. tag) is available. Yeah, I get that it can be a bit better than async with a similar slowdown, but there's little value in catching only reads from the security standpoint. > > So the current code that you have should work perfectly. The only > > change I'd like to see is in the documentation. > > Something like this (or more?) > > diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/= kasan.rst > index 7f37a46af574..3c58392d931e 100644 > --- a/Documentation/dev-tools/kasan.rst > +++ b/Documentation/dev-tools/kasan.rst > @@ -135,6 +135,8 @@ disabling KASAN altogether or controlling its feature= s: > fault occurs, the information is stored in hardware (in the TFSR_EL1 > register for arm64). The kernel periodically checks the hardware and > only reports tag faults during these checks. > + Note that ``kasan.fault=3Dpanic_on_write`` results in panic for all > + asynchronously checked accesses. > Asymmetric mode: a bad access is detected synchronously on reads and > asynchronously on writes. Could you move this to the section that describes the kasan.fault flag? This seems more consistent. Thanks!