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=-24.8 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_SANE_1,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 A9A59C433E0 for ; Fri, 12 Mar 2021 15:08:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 197A664F80 for ; Fri, 12 Mar 2021 15:08:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 197A664F80 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 AD4526B0070; Fri, 12 Mar 2021 10:08:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A838C6B0071; Fri, 12 Mar 2021 10:08:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8D7156B0072; Fri, 12 Mar 2021 10:08:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0135.hostedemail.com [216.40.44.135]) by kanga.kvack.org (Postfix) with ESMTP id 6E12A6B0070 for ; Fri, 12 Mar 2021 10:08:14 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 1BD971800746D for ; Fri, 12 Mar 2021 15:08:14 +0000 (UTC) X-FDA: 77911552908.16.34FBEFA Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) by imf28.hostedemail.com (Postfix) with ESMTP id 922742000D89 for ; Fri, 12 Mar 2021 15:08:13 +0000 (UTC) Received: by mail-wm1-f44.google.com with SMTP id y124-20020a1c32820000b029010c93864955so16005626wmy.5 for ; Fri, 12 Mar 2021 07:08:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=11LkVFc2ai96+FS3xzLxLBdovdC4Bzzrs8ahU7qpmeI=; b=lUp7M+IiivkbRqlrmnLkQeZkCcfqBJxzLShB6QIW1KqBf1fb0GVlVGCijS5s31b96N lARfpP7EUB8sKtlYdlbHiAio0Y+Us6d6ZZERyoLmxXKMQS6qJ1yS7w4lzgujFBBFIaGp lvG5zEeHeoE58lBSZNVXTJYzxVlH86jwQ9nDxKWibmozu+8Ck/UwbJ1NpJC07KbexKR3 aJ0QGmrmdKWcl77uJE8gPJtCQHycRWIjnR8TE0RamD0Py5WYFtPvi05XYIJLOHjEfYUb jscaR2ipeCPeefxKgQlqWDTbuAD6W+NjAqGyiPYcGDPrT0wOGCol3lF3ikm5J/ac5n0f zNcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=11LkVFc2ai96+FS3xzLxLBdovdC4Bzzrs8ahU7qpmeI=; b=RkEbiDe9TtdZJpig0Hr81rYnrLx9Na4wcBGSrBrh563qi+8xaSpeH5mh2bm7X94XMs ciCGGyikz7vBN5l2ymancZCXeGDxMwR65bkvenD1L66p8HMEDbXBFDcX40QTBMEOfazc psJSx2QGRu/TOrXR8ePO+3J1RqJU+27MlVu/Z3a6BF6D4nM4QHOKtG99tPFdyCMrbV/i 50ig3F11qt4R1k1pAqF2slbJ3T+U+pYkrpIWIEf5ttgay0NKxyV2YEfcOa7OA204EG3R ucK/2YNpIDhJUjtdPWlwCzsWpTxLfXqfgJmNfgUJTvtd0hGug4yHTrGX0uBSKsdp2KL1 LyOQ== X-Gm-Message-State: AOAM533epWO3gcEkeEgYyrtbVgmfTvx5QHIgOoF4VCutDns/ePAdT6Rv eQ0Vc3gvB0GYDqml2bu/QuQjFw== X-Google-Smtp-Source: ABdhPJxMj+nON4YnTgXAyWfAAEBbOaJIKzefApKvXJINUWhVIyEe28Hvb/8UyqT2wS9MzYtINtwgrg== X-Received: by 2002:a05:600c:289:: with SMTP id 9mr13639929wmk.135.1615561690926; Fri, 12 Mar 2021 07:08:10 -0800 (PST) Received: from elver.google.com ([2a00:79e0:15:13:d5de:d45f:f79c:cb62]) by smtp.gmail.com with ESMTPSA id w131sm2400544wmb.8.2021.03.12.07.08.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Mar 2021 07:08:10 -0800 (PST) Date: Fri, 12 Mar 2021 16:08:04 +0100 From: Marco Elver To: Andrey Konovalov Cc: Andrew Morton , Alexander Potapenko , Andrey Ryabinin , Dmitry Vyukov , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 04/11] kasan: docs: update error reports section Message-ID: References: <3531e8fe6972cf39d1954e3643237b19eb21227e.1615559068.git.andreyknvl@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3531e8fe6972cf39d1954e3643237b19eb21227e.1615559068.git.andreyknvl@google.com> User-Agent: Mutt/2.0.5 (2021-01-21) X-Stat-Signature: tc8fg4cx4amtj1nu5kte8qz4qx98s4np X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 922742000D89 Received-SPF: none (google.com>: No applicable sender policy available) receiver=imf28; identity=mailfrom; envelope-from=""; helo=mail-wm1-f44.google.com; client-ip=209.85.128.44 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615561693-978921 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 Fri, Mar 12, 2021 at 03:24PM +0100, Andrey Konovalov wrote: > 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 Reviewed-by: Marco Elver > --- > 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 46f4e9680805..cd12c890b888 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). > > -- > 2.31.0.rc2.261.g7f71774620-goog >