From: Brian Johannesmeyer <bjohannesmeyer@gmail.com>
To: Alexander Potapenko <glider@google.com>
Cc: Marco Elver <elver@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
kasan-dev@googlegroups.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kmsan: introduce test_unpoison_memory()
Date: Tue, 28 May 2024 17:45:12 +0200 [thread overview]
Message-ID: <ZlX8CLwwtv5ry7FZ@rex> (raw)
In-Reply-To: <CAG_fn=U2U5j8VxrkKGHEOdbpheVXM08ExFwkqNhz4qv2EtTjWg@mail.gmail.com>
On Tue, May 28, 2024 at 12:20:15PM +0200, Alexander Potapenko wrote:
> You are right with your analysis.
> KMSAN stores a single origin for every aligned four-byte granule of
> memory, so we lose some information when more than one uninitialized
> value is combined in that granule.
> When writing an uninitialized value to memory, a viable strategy is to
> always update the origin. But if we partially initialize the granule
> with a store, it is better to preserve that granule's origin to
> prevent false negatives, so we need to check the resulting shadow slot
> before updating the origin.
> This is what the compiler instrumentation does, so
> kmsan_internal_set_shadow_origin() should behave in the same way.
> I found a similar bug in kmsan_internal_memmove_metadata() last year,
> but missed this one.
I appreciate the explanation. Makes sense.
> I am going to send a patch fixing this along with your test (with an
> updated description), if you don't object.
Yes, that's fine. Thank you.
-Brian
prev parent reply other threads:[~2024-05-28 15:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-24 23:28 [PATCH] kmsan: introduce test_unpoison_memory() Brian Johannesmeyer
2024-05-28 10:20 ` Alexander Potapenko
2024-05-28 15:45 ` Brian Johannesmeyer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZlX8CLwwtv5ry7FZ@rex \
--to=bjohannesmeyer@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.