Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp165813pxb; Fri, 15 Jan 2021 09:55:05 -0800 (PST) X-Google-Smtp-Source: ABdhPJyXGJCzOLPglVOeNOMz9F5z/SVVNTZTKOVO/B5/YCdxeOA26Iw15HiN49wmiTocscM0eiv2 X-Received: by 2002:a17:907:2116:: with SMTP id qn22mr9642073ejb.483.1610733305135; Fri, 15 Jan 2021 09:55:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610733305; cv=none; d=google.com; s=arc-20160816; b=xOcemz8jA++tZ1MbTdNAWZousHzUL6lbJP9Ttb6kv9Htnd8+XWeWpgJwPWKR99IC3O NwaOvIc6pBaCPHjdavmBtuifB/nbsChDutPjDe2MwEdV6RJtllXXlhCx7esM2VnruAcm LF3fYGIgEEtNYQ3Tir2uEb2IXulWNWG3WiMLfcHjNnjs9wHQXZradi8ZnEhYD0sj2Rim z3rDmEqK7RgA+qAen5YwY+9AhH7qGDUsTJhninGl7qwrWghthqtGMS03gDFvXKao4qOS iiaqY9RRxUUsCAC9lTCaSWMdJq2nPp15OrMlivnqSkojXOnY2k8Id0agEtPuufhcIsCu 9noQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:references:mime-version :message-id:in-reply-to:date:sender:dkim-signature; bh=d+lRqXXla6mV/kMKnUzgl/DAB69C3QZUVHCf/SWSD4s=; b=XJame34pMj7OppYPQ7B+Ik95+5eFrTGFmmde+1yWLtSdIlWCoGbCTxmcZXHRm1lvw1 qnF9VSGzIh8AQ5yD0ZuYcCGWXMXxpW4NLXmHB+kQtlwhbegXk2zbMpyVayFbG7KpybWk ZxDhq7gWtcU9u0l4VaAG6I5p9tx66Y9+AfVx0StQCc4Ke0Jne7honoXljl8Z+aI7NtnD MnKyGVGxdWc4hMc2jStLEipZmJVdaU/c1de55R3VrmSyNLp/wT9Ly0w+iDsG+b3OmHXs Yn70tyqjgZ1Vuy+M2qPHGDG8t+N3xfOEXdmoHWr4vaEApTgl1pRCHb7YqTNBlKSa4FeR 1IpA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=KgXsADO6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b20si4188521ejk.726.2021.01.15.09.54.41; Fri, 15 Jan 2021 09:55:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=KgXsADO6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729353AbhAORxq (ORCPT + 99 others); Fri, 15 Jan 2021 12:53:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52006 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726355AbhAORxq (ORCPT ); Fri, 15 Jan 2021 12:53:46 -0500 Received: from mail-wm1-x349.google.com (mail-wm1-x349.google.com [IPv6:2a00:1450:4864:20::349]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8A24EC061793 for ; Fri, 15 Jan 2021 09:53:05 -0800 (PST) Received: by mail-wm1-x349.google.com with SMTP id u67so555389wmb.0 for ; Fri, 15 Jan 2021 09:53:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=sender:date:in-reply-to:message-id:mime-version:references:subject :from:to:cc; bh=d+lRqXXla6mV/kMKnUzgl/DAB69C3QZUVHCf/SWSD4s=; b=KgXsADO6gYG+QvJv8VSvdUb8Ltjmd7v7h/iXf4vB+MUx9Hgoo/jNS+Vf6CaL2wEuKc iZx+uRlsmSmChjKZB8PeM+2dY6z/JyFIFLWBbNw1VAx4D2M/iXObjUzCZ7fBSfeX3u0r 5YfdIu95gEZandu93MmDpCwNWtqhZpPlSmmjfvOZLYE9Sbuujc+aqXC2qj2elqLEJ9VM RaDCLzvWaX5/2oD76eVUv0i6nIfmJk8vOryRmLyptUhh9nWI1mtpqlx+Yn/uT4oybi6f oNtAzPYrqpulLvHqnis8loKBQl943FBAFrdnh9YV5x3XZP96MO3+h0totSFQGrfhOew9 8ylg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=d+lRqXXla6mV/kMKnUzgl/DAB69C3QZUVHCf/SWSD4s=; b=QalfEh3SK2Yw9vAqQ3Ggi1k1Zcy6PmM2uY6wByNTQ+iybEjSC7jIHVJnX2U5qxjBme V7Va+mcMiB6XSsHdNL8CigfBGAyjAiGGB0p2CgpZThyY2QFruzXBkuq50Nn47kLwkF9U idgQ6kSf1loK51inIc0FcqC7ZEK4Kxo7F2p4I09+JU6lUHWvgXLfGzPqhdvYmglWgxmS kEK1x34CfQVgf606IPCsUAYcoablP/BjQpRhr/7WOB7CAv8BbimaR4yln5NV55OceHL2 oKLWZpz3tOxIBedy8sYJ2fURGHACes874AK7Dw9qOMqYxfCDQBar7+YdXYUphTc0hSO4 3Nng== X-Gm-Message-State: AOAM532nsaVruXxumAbK2htV0IUvYb6KIGzxZgVMnm33NitLZ74Wvxwf IXCbayTJaoi8O1reEjI9X9LGsfT6eurl9I54 Sender: "andreyknvl via sendgmr" X-Received: from andreyknvl3.muc.corp.google.com ([2a00:79e0:15:13:7220:84ff:fe09:7e9d]) (user=andreyknvl job=sendgmr) by 2002:adf:e60f:: with SMTP id p15mr14224523wrm.60.1610733184113; Fri, 15 Jan 2021 09:53:04 -0800 (PST) Date: Fri, 15 Jan 2021 18:52:39 +0100 In-Reply-To: Message-Id: <3b4ea6875bb14d312092ad14ac55cb456c83c08e.1610733117.git.andreyknvl@google.com> Mime-Version: 1.0 References: X-Mailer: git-send-email 2.30.0.284.gd98b1dd5eaa7-goog Subject: [PATCH v4 02/15] kasan: clarify HW_TAGS impact on TBI From: Andrey Konovalov To: Andrew Morton , Catalin Marinas , Vincenzo Frascino , Dmitry Vyukov , Alexander Potapenko , Marco Elver Cc: Will Deacon , Andrey Ryabinin , Peter Collingbourne , Evgenii Stepanov , Branislav Rankov , Kevin Brodsky , 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mention in the documentation that enabling CONFIG_KASAN_HW_TAGS always results in in-kernel TBI (Top Byte Ignore) being enabled. Also do a few minor documentation cleanups. Link: https://linux-review.googlesource.com/id/Iba2a6697e3c6304cb53f89ec61dedc77fa29e3ae Reviewed-by: Marco Elver Reviewed-by: Alexander Potapenko Signed-off-by: Andrey Konovalov --- Documentation/dev-tools/kasan.rst | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst index 0fc3fb1860c4..26c99852a852 100644 --- a/Documentation/dev-tools/kasan.rst +++ b/Documentation/dev-tools/kasan.rst @@ -147,15 +147,14 @@ negative values to distinguish between different kinds of inaccessible memory like redzones or freed memory (see mm/kasan/kasan.h). In the report above the arrows point to the shadow byte 03, which means that -the accessed address is partially accessible. - -For tag-based KASAN this last report section shows the memory tags around the -accessed address (see `Implementation details`_ section). +the accessed address is partially accessible. For tag-based KASAN modes this +last report section shows the memory tags around the accessed address +(see the `Implementation details`_ section). Boot parameters ~~~~~~~~~~~~~~~ -Hardware tag-based KASAN mode (see the section about different mode below) is +Hardware tag-based KASAN mode (see the section about various modes below) is intended for use in production as a security mitigation. Therefore it supports boot parameters that allow to disable KASAN competely or otherwise control particular KASAN features. @@ -305,6 +304,13 @@ reserved to tag freed memory regions. Hardware tag-based KASAN currently only supports tagging of kmem_cache_alloc/kmalloc and page_alloc memory. +If the hardware doesn't support MTE (pre ARMv8.5), hardware tag-based KASAN +won't be enabled. In this case all boot parameters are ignored. + +Note, that enabling CONFIG_KASAN_HW_TAGS always results in in-kernel TBI being +enabled. Even when kasan.mode=off is provided, or when the hardware doesn't +support MTE (but supports TBI). + What memory accesses are sanitised by KASAN? -------------------------------------------- -- 2.30.0.284.gd98b1dd5eaa7-goog