Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1285453pxf; Fri, 12 Mar 2021 06:29:03 -0800 (PST) X-Google-Smtp-Source: ABdhPJwb8LLkQjkdW5YIEoItfW5pfoSCEVNC60fIjuTYltSlmImjc1Ny/h6yyyjivF36XHcfWY1w X-Received: by 2002:a17:907:766f:: with SMTP id kk15mr8924587ejc.24.1615559343642; Fri, 12 Mar 2021 06:29:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615559343; cv=none; d=google.com; s=arc-20160816; b=KaP/4y7cFGBrPlvOGdZworB5HF33awK0x3TWf6uqxatGUS+UMXJGSQY03EKZ4mjDin 52dM8ufVt0HlrBaGjPLPjRVgE44Lcxmq4Ao00L9SJJychZMnOs3mXu0I1HumFPk0n+WO 67QoIFPtoaDq6FOTKUnlMFoMSqpIQQvhglky3eopv9CFgKwIVQ0Nzjpl9ODqHJK6yTUu P+SLC4OHY1L4P/T2kx25fIvvcLLGD2JJwUkTZK5Vtwss9cFF0SD5OhKCm2C63V+j3Bg7 0cGP5w4KrHCjanKP7CJ2hI+DsAPzuX0EgWS//D2Br0HmHPySg6IihcfVRL+5r3UCmo48 Fl7w== 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:dkim-signature; bh=Ygfy34R30Ir5P43bAuVWD7PsEpaVeYrJUsfKdxJOhKs=; b=P/gQIxPRXlDZsborKJMmnIEuVj9HrfMUcA32yK6Sm+zR68qe0wqbVytiU5bh3dAQxG 32Gj7D9TlMo9kd5T/R/dhEb2cUgrsXbspizy9dblPC0JJGmSrR9V3lvJU1PfdHx+RT6x E6sBIX6c3b7LQbVNED/s/AHRNV1uQ++OEtZymEEUvn3sewVzh6EYId+0K0wP6x7i2Nxi OFCgCltErZT92gQ8fbFN0SAZlX9LXUDJFOchAO78lUWBqNnWv+pzkc07devDo61GK4ZO +5TgZ9aSEyL7050a5065Vp7sfjAnJUOevm45TPTASlC9DgBNX17Lq7TZoAamt2G4O/cA eJzw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=rC5oeVOt; 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 b26si4418508ejb.374.2021.03.12.06.28.41; Fri, 12 Mar 2021 06:29:03 -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=rC5oeVOt; 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 S232266AbhCLOZe (ORCPT + 99 others); Fri, 12 Mar 2021 09:25:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58136 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232244AbhCLOZB (ORCPT ); Fri, 12 Mar 2021 09:25:01 -0500 Received: from mail-wr1-x449.google.com (mail-wr1-x449.google.com [IPv6:2a00:1450:4864:20::449]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F194DC061574 for ; Fri, 12 Mar 2021 06:25:00 -0800 (PST) Received: by mail-wr1-x449.google.com with SMTP id r12so11240515wro.15 for ; Fri, 12 Mar 2021 06:25:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:in-reply-to:message-id:mime-version:references:subject:from:to :cc; bh=Ygfy34R30Ir5P43bAuVWD7PsEpaVeYrJUsfKdxJOhKs=; b=rC5oeVOtwW4j37sI8e0pI6DstMXXrDhg66shdjo/HdwFQuJql7l9XihT1b74K7zfvu +LMZjin/QNQW1inNez0NvU7o976i056UEY83jBhxXulKZh6DQMsHam+O+rTQLzLGCzmr tN3mgw7nzkn9DE5HZ+CQpqrDn1rVhghN3essH34emvOhlYdE9vQ115ZaFgV0UC7h4urG 39CWaz23zdSYXKZZzs7gNqzSk1aKHKyw1XCLtRuu/NJeiNRw/SEJDhBh0MZ5Vxp+J0GM JZnpHWL8trHR2Z8bs3OeGJoXIJqxcVqem5ARckJOk1XY3jW1rOk0XuSPTY++Y+xTm5+P J3jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=Ygfy34R30Ir5P43bAuVWD7PsEpaVeYrJUsfKdxJOhKs=; b=MMZEswrZYMMsg1OHR6ExJHi6E0+EhdbXJJ1m7cltfXk4p68WTaaMGZtdWzO8ofGQ1h Oag8HbHAMFJDWmAQ/a6ATxPoGgJtwnQBd176a+NixdGoqoQNJdfWiSF/WVjf2LnNZ1uG 3h0AGswokycPZz1Tm3mU/FO0nC7H1bUCO97t1y5PJzJwC1yZSltdQaankPjO3p+RIqUG XeA8YhaVmOG5VLIEklByWBWcwQiUm8lMowBe9daFnu6z4YWH1bxuZtdQ7XCHXrCu+2jT nS+/HaszPxhbCobgZeWc88oSX2r8se+4JbHYhJMSY8X7LT0B9nsBV9mhx9cvfhuAc/Zo ZXcQ== X-Gm-Message-State: AOAM530eQn5zPyJsuo9mTiaDw2kmSCxs5Jcxe7hCWHIOk8spU+syPSYa rl3t0WrAK7seAifqEuTkiL1vT50rmjy1V4/C X-Received: from andreyknvl3.muc.corp.google.com ([2a00:79e0:15:13:95a:d8a8:4925:42be]) (user=andreyknvl job=sendgmr) by 2002:a1c:5416:: with SMTP id i22mr13379263wmb.146.1615559099696; Fri, 12 Mar 2021 06:24:59 -0800 (PST) Date: Fri, 12 Mar 2021 15:24:33 +0100 In-Reply-To: Message-Id: <4531ba5f3eca61f6aade863c136778cc8c807a64.1615559068.git.andreyknvl@google.com> Mime-Version: 1.0 References: X-Mailer: git-send-email 2.31.0.rc2.261.g7f71774620-goog Subject: [PATCH v2 10/11] kasan: docs: update ignoring accesses section From: Andrey Konovalov To: Andrew Morton , Alexander Potapenko , Marco Elver Cc: Andrey Ryabinin , Dmitry Vyukov , kasan-dev@googlegroups.com, 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 Update the "Ignoring accesses" section in KASAN documentation: - Mention __no_sanitize_address/noinstr. - Mention kasan_disable/enable_current(). - Mention kasan_reset_tag()/page_kasan_tag_reset(). - Readability and punctuation clean-ups. Signed-off-by: Andrey Konovalov --- Changes in v1->v2: - Mention __no_sanitize_address/noinstr. - Reword the whole section to make it clear which method works for which mode. --- Documentation/dev-tools/kasan.rst | 34 +++++++++++++++++++++++++++---- 1 file changed, 30 insertions(+), 4 deletions(-) diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst index d0c1796122df..5749c14b38d0 100644 --- a/Documentation/dev-tools/kasan.rst +++ b/Documentation/dev-tools/kasan.rst @@ -368,12 +368,18 @@ Ignoring accesses ~~~~~~~~~~~~~~~~~ Software KASAN modes use compiler instrumentation to insert validity checks. -Such instrumentation might be incompatible with some part of the kernel, and -therefore needs to be disabled. To disable instrumentation for specific files -or directories, add a line similar to the following to the respective kernel +Such instrumentation might be incompatible with some parts of the kernel, and +therefore needs to be disabled. + +Other parts of the kernel might access metadata for allocated objects. +Normally, KASAN detects and reports such accesses, but in some cases (e.g., +in memory allocators), these accesses are valid. + +For software KASAN modes, to disable instrumentation for a specific file or +directory, add a ``KASAN_SANITIZE`` annotation to the respective kernel Makefile: -- For a single file (e.g. main.o):: +- For a single file (e.g., main.o):: KASAN_SANITIZE_main.o := n @@ -381,6 +387,26 @@ Makefile: KASAN_SANITIZE := n +For software KASAN modes, to disable instrumentation on a per-function basis, +use the KASAN-specific ``__no_sanitize_address`` function attribute or the +generic ``noinstr`` one. + +Note that disabling compiler instrumentation (either on a per-file or a +per-function basis) makes KASAN ignore the accesses that happen directly in +that code for software KASAN modes. It does not help when the accesses happen +indirectly (through calls to instrumented functions) or with the hardware +tag-based mode that does not use compiler instrumentation. + +For software KASAN modes, to disable KASAN reports in a part of the kernel code +for the current task, annotate this part of the code with a +``kasan_disable_current()``/``kasan_enable_current()`` section. This also +disables the reports for indirect accesses that happen through function calls. + +For tag-based KASAN modes (include the hardware one), to disable access +checking, use ``kasan_reset_tag()`` or ``page_kasan_tag_reset()``. Note that +temporarily disabling access checking via ``page_kasan_tag_reset()`` requires +saving and restoring the per-page KASAN tag via +``page_kasan_tag``/``page_kasan_tag_set``. Tests ~~~~~ -- 2.31.0.rc2.261.g7f71774620-goog