From patchwork Thu Mar 11 21:37:16 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrey Konovalov X-Patchwork-Id: 12132949 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=-26.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT,USER_IN_DEF_DKIM_WL 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 5E72CC433DB for ; Thu, 11 Mar 2021 21:37:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E2F1F64F8F for ; Thu, 11 Mar 2021 21:37:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E2F1F64F8F 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 73C798D02FC; Thu, 11 Mar 2021 16:37:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6EB638D02B2; Thu, 11 Mar 2021 16:37:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4F0E38D02FC; Thu, 11 Mar 2021 16:37:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0246.hostedemail.com [216.40.44.246]) by kanga.kvack.org (Postfix) with ESMTP id 2792C8D02B2 for ; Thu, 11 Mar 2021 16:37:36 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id C735D824999B for ; Thu, 11 Mar 2021 21:37:35 +0000 (UTC) X-FDA: 77908905270.30.CAA954B Received: from mail-qt1-f201.google.com (mail-qt1-f201.google.com [209.85.160.201]) by imf01.hostedemail.com (Postfix) with ESMTP id AEC18200038A for ; Thu, 11 Mar 2021 21:37:35 +0000 (UTC) Received: by mail-qt1-f201.google.com with SMTP id k4so16582188qtd.20 for ; Thu, 11 Mar 2021 13:37:35 -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=Z5eOirVQs3kFMVVYLPwNbYTFfp7Ms1nJ3eBbZNg7oSE=; b=ss9oJe0pM2ElU/I3jSTTIlzmBUFKVJwse1lMSmfbJC3heqvzN6V6cu3CVowDOoIys7 rHMW8ZRVxkgSQlriCc4puO8sQCLF4m52Eo7IvUY49QDarKLJYOtK6OA4Ulvgcrs5jMLJ 0frkrdx99oF6gVY8/+c6aadOP0Sm5IPEodDeKW00DgiskPb06OwXLLcaGoFCFAFb02We 4RaGm9dQxKxdpEJ5Smlg67KHtZJ4/ZGTU/9xSWGC5mt8nD8ct0o6fNh5RoUkDWOBFMxZ 4HacTXoIMjA7mgORYCvPh35ywI0iWSlVW8T1j1N8iEmg+PCR69tuDedRH8+TrZPo3mMi Z8nQ== 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=Z5eOirVQs3kFMVVYLPwNbYTFfp7Ms1nJ3eBbZNg7oSE=; b=f6vGavx0TLzp4Vg6bGLFmmXn+VmaJCuMkU4kOMc32TeK3OeSByH94ceev4HgSzHlGX IUklbtqkH34r99o0C4VmwhVUFym7uGR52eNHPh+vXks+9mWC+BQ2nYWUpfcxJbzte9v7 RTa+4wEi4xDTGeZtZ/v9/w6Ky/7T3oKX33Hu791z430SGYqthz1QFHac2Hrsrx1dYZfD TWgiBy8zdubqfqIFOtOnC08Iwsju6fbPTiaeYA6PZ6ysqot+9Lvj2PKWHq06y7XW478u ++Kjq4lp4ykA3JdLBYgpmFvNv9xzf+YM00zdiI4itgXzKxoZnFfMNFccEhrA+2f1VNPa aETw== X-Gm-Message-State: AOAM532XXLehziwH71n36I0e7IaspgRpxil0GYZESPnvfmUnG9a3Gps7 xny5gnJHGewEIg5CN0ObntchSY0ZnHNhsl7B X-Google-Smtp-Source: ABdhPJwtC+4faGTKQmjBS8T6FlPpbYJS3wpQopaKe7j5nNJcKaN9acXfERXOjuleqJBSaw58Zbaz0cv45QLzR4Fs X-Received: from andreyknvl3.muc.corp.google.com ([2a00:79e0:15:13:95a:d8a8:4925:42be]) (user=andreyknvl job=sendgmr) by 2002:a0c:c248:: with SMTP id w8mr9669098qvh.58.1615498654537; Thu, 11 Mar 2021 13:37:34 -0800 (PST) Date: Thu, 11 Mar 2021 22:37:16 +0100 In-Reply-To: Message-Id: Mime-Version: 1.0 References: X-Mailer: git-send-email 2.31.0.rc2.261.g7f71774620-goog Subject: [PATCH 04/11] kasan: docs: update error reports 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 X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: AEC18200038A X-Stat-Signature: r3pfqk9aqtphxc1hzjspqwntoob3k1n9 Received-SPF: none (flex--andreyknvl.bounces.google.com>: No applicable sender policy available) receiver=imf01; identity=mailfrom; envelope-from="<3no1KYAoKCOsNaQeRlXaiYTbbTYR.PbZYVahk-ZZXiNPX.beT@flex--andreyknvl.bounces.google.com>"; helo=mail-qt1-f201.google.com; client-ip=209.85.160.201 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615498655-860747 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: Update the "Error reports" section in KASAN documentation: - Mention that bug titles are best-effort. - Move and reword the part about auxiliary stacks from "Implementation details". - Punctuation, readability, and other minor clean-ups. Signed-off-by: Andrey Konovalov --- Documentation/dev-tools/kasan.rst | 46 +++++++++++++++++-------------- 1 file changed, 26 insertions(+), 20 deletions(-) diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst index f21c0cbebcb3..5fe43489e94e 100644 --- a/Documentation/dev-tools/kasan.rst +++ b/Documentation/dev-tools/kasan.rst @@ -60,7 +60,7 @@ physical pages, enable ``CONFIG_PAGE_OWNER`` and boot with ``page_owner=on``. Error reports ~~~~~~~~~~~~~ -A typical out-of-bounds access generic KASAN report looks like this:: +A typical KASAN report looks like this:: ================================================================== BUG: KASAN: slab-out-of-bounds in kmalloc_oob_right+0xa8/0xbc [test_kasan] @@ -133,33 +133,43 @@ A typical out-of-bounds access generic KASAN report looks like this:: ffff8801f44ec400: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== -The header of the report provides a short summary of what kind of bug happened -and what kind of access caused it. It's followed by a stack trace of the bad -access, a stack trace of where the accessed memory was allocated (in case bad -access happens on a slab object), and a stack trace of where the object was -freed (in case of a use-after-free bug report). Next comes a description of -the accessed slab object and information about the accessed memory page. +The report header summarizes what kind of bug happened and what kind of access +caused it. It is followed by a stack trace of the bad access, a stack trace of +where the accessed memory was allocated (in case a slab object was accessed), +and a stack trace of where the object was freed (in case of a use-after-free +bug report). Next comes a description of the accessed slab object and the +information about the accessed memory page. -In the last section the report shows memory state around the accessed address. -Internally KASAN tracks memory state separately for each memory granule, which +In the end, the report shows the memory state around the accessed address. +Internally, KASAN tracks memory state separately for each memory granule, which is either 8 or 16 aligned bytes depending on KASAN mode. Each number in the memory state section of the report shows the state of one of the memory granules that surround the accessed address. -For generic KASAN the size of each memory granule is 8. The state of each +For generic KASAN, the size of each memory granule is 8. The state of each granule is encoded in one shadow byte. Those 8 bytes can be accessible, -partially accessible, freed or be a part of a redzone. KASAN uses the following -encoding for each shadow byte: 0 means that all 8 bytes of the corresponding +partially accessible, freed, or be a part of a redzone. KASAN uses the following +encoding for each shadow byte: 00 means that all 8 bytes of the corresponding memory region are accessible; number N (1 <= N <= 7) means that the first N bytes are accessible, and other (8 - N) bytes are not; any negative value indicates that the entire 8-byte word is inaccessible. KASAN uses different 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 modes this -last report section shows the memory tags around the accessed address -(see the `Implementation details`_ section). +In the report above, the arrow points to the shadow byte ``03``, which means +that 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). + +Note that KASAN bug titles (like ``slab-out-of-bounds`` or ``use-after-free``) +are best-effort: KASAN prints the most probable bug type based on the limited +information it has. The actual type of the bug might be different. + +Generic KASAN also reports up to two auxiliary call stack traces. These stack +traces point to places in code that interacted with the object but that are not +directly present in the bad access stack trace. Currently, this includes +call_rcu() and workqueue queuing. Boot parameters ~~~~~~~~~~~~~~~ @@ -214,10 +224,6 @@ function calls GCC directly inserts the code to check the shadow memory. This option significantly enlarges kernel but it gives x1.1-x2 performance boost over outline instrumented kernel. -Generic KASAN also reports the last 2 call stacks to creation of work that -potentially has access to an object. Call stacks for the following are shown: -call_rcu() and workqueue queuing. - Generic KASAN is the only mode that delays the reuse of freed object via quarantine (see mm/kasan/quarantine.c for implementation).