linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Potapenko <glider@google.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>,  "Theodore Ts'o" <tytso@mit.edu>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	 "Martin K . Petersen" <martin.petersen@oracle.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	 Christoph Hellwig <hch@lst.de>,
	Eric Dumazet <edumazet@google.com>,
	Eric Van Hensbergen <ericvh@gmail.com>,
	 Takashi Iwai <tiwai@suse.com>,
	Vegard Nossum <vegard.nossum@oracle.com>,
	 Dmitry Vyukov <dvyukov@google.com>,
	Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [PATCH RFC v1 23/26] kmsan: unpoisoning buffers from devices etc.
Date: Tue, 29 Oct 2019 15:45:29 +0100	[thread overview]
Message-ID: <CAG_fn=WYP1fqonfHM-RSNNpnFDe0AnonmgcuY_rf_7LXjKA9hw@mail.gmail.com> (raw)
In-Reply-To: <20191018162222.GM32665@bombadil.infradead.org>

On Fri, Oct 18, 2019 at 6:22 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Fri, Oct 18, 2019 at 11:43:01AM +0200, glider@google.com wrote:
> > When data is copied to memory from a device KMSAN should treat it as
> > initialized. In most cases it's enough to just unpoison the buffer that
> > is known to come from a device.
> > In the case with __do_page_cache_readahead() and bio_copy_user_iov() we
> > have to mark the whole pages as ignored by KMSAN, as it's not obvious
> > where these pages are read again.
>
> ...
>
> > +++ b/mm/filemap.c
> > @@ -18,6 +18,7 @@
> >  #include <linux/uaccess.h>
> >  #include <linux/capability.h>
> >  #include <linux/kernel_stat.h>
> > +#include <linux/kmsan-checks.h>
> >  #include <linux/gfp.h>
> >  #include <linux/mm.h>
> >  #include <linux/swap.h>
> > @@ -2810,6 +2811,8 @@ static struct page *do_read_cache_page(struct address_space *mapping,
> >               page = wait_on_page_read(page);
> >               if (IS_ERR(page))
> >                       return page;
> > +             /* Assume all pages in page cache are initialized. */
> > +             kmsan_unpoison_shadow(page_address(page), PAGE_SIZE);
>
> Why would you do that?  The page cache already keeps track of which
> pages are initialised -- the PageUptodate flag is set on them.  Indeed,
> just adding a kmsan call to SetPageUptodate and __SetPageUptodate would
> probably be a very straightforward way of handling things, and probably
> means you can get rid of a lot of these other calls.
This seems like a very good thing to do, I'll definitely try that.
I however noticed that __SetPageUptodate is used when copying pages,
not during disk I/O. Is that really so?

We basically need the following behavior: if a device writes to a
page, the contents of that page are considered initialized.
However when the kernel copies one page to another, we must explicitly
copy the source shadow page to the destination.

On a related note, there seems to be a PG_dirty bit that indicates the
page is to be flushed to disk.
What's the best place to check such pages for being initialized, so
that we can also report writes of uninitialized data to the disk?


-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg


  reply	other threads:[~2019-10-29 14:45 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-18  9:42 [PATCH RFC v1 00/26] Add KernelMemorySanitizer infrastructure glider
2019-10-18  9:42 ` [PATCH RFC v1 01/26] stackdepot: check depot_index before accessing the stack slab glider
2019-10-18  9:42 ` [PATCH RFC v1 02/26] stackdepot: prevent Clang from optimizing away stackdepot_memcmp() glider
2019-10-18  9:42 ` [PATCH RFC v1 03/26] kasan: stackdepot: move filter_irq_stacks() to stackdepot.c glider
2019-10-18  9:42 ` [PATCH RFC v1 04/26] stackdepot: reserve 5 extra bits in depot_stack_handle_t glider
2019-10-18  9:42 ` [PATCH RFC v1 05/26] printk_safe: externalize printk_context glider
2019-10-21  9:09   ` Petr Mladek
2019-10-23 17:57     ` Alexander Potapenko
2019-10-23 18:00       ` Alexander Potapenko
2019-10-24 12:46       ` Petr Mladek
2019-10-28 13:09         ` Alexander Potapenko
2019-10-29 12:02           ` Petr Mladek
2019-10-29 12:45             ` Alexander Potapenko
2019-10-18  9:42 ` [PATCH RFC v1 06/26] kasan: compiler.h: rename __no_kasan_or_inline into __no_memory_tool_or_inline glider
2019-10-18  9:42 ` [PATCH RFC v1 07/26] kmsan: add ReST documentation glider
2019-10-18  9:42 ` [PATCH RFC v1 08/26] kmsan: gfp: introduce __GFP_NO_KMSAN_SHADOW glider
2019-10-18  9:42 ` [PATCH RFC v1 09/26] kmsan: introduce __no_sanitize_memory and __SANITIZE_MEMORY__ glider
2019-10-18  9:42 ` [PATCH RFC v1 10/26] kmsan: reduce vmalloc space glider
2019-10-18  9:42 ` [PATCH RFC v1 11/26] kmsan: add KMSAN runtime glider
2019-10-18  9:42 ` [PATCH RFC v1 12/26] kmsan: x86: sync metadata pages on page fault glider
2019-10-18  9:42 ` [PATCH RFC v1 13/26] kmsan: add tests for KMSAN glider
2019-10-18  9:42 ` [PATCH RFC v1 14/26] kmsan: make READ_ONCE_TASK_STACK() return initialized values glider
2019-10-18  9:42 ` [PATCH RFC v1 15/26] kmsan: Kconfig changes to disable options incompatible with KMSAN glider
2019-10-21 14:11   ` Harry Wentland
2019-10-18  9:42 ` [PATCH RFC v1 16/26] kmsan: Changing existing files to enable KMSAN builds glider
2019-10-18  9:42 ` [PATCH RFC v1 17/26] kmsan: disable KMSAN instrumentation for certain kernel parts glider
2019-10-18  9:42 ` [PATCH RFC v1 18/26] kmsan: mm: call KMSAN hooks from SLUB code glider
2019-10-18 13:22   ` Qian Cai
2019-10-18 13:33     ` Alexander Potapenko
2019-10-18 13:41       ` Qian Cai
2019-10-18 13:55         ` Alexander Potapenko
2019-10-18 14:42           ` Qian Cai
2019-10-18 14:54             ` Alexander Potapenko
2019-10-18 15:13               ` Qian Cai
2019-10-18 15:30                 ` Alexander Potapenko
2019-10-18 16:08                   ` Qian Cai
2019-10-18  9:42 ` [PATCH RFC v1 19/26] kmsan: call KMSAN hooks where needed glider
2019-10-18 15:02   ` Qian Cai
2019-10-29 14:09     ` Alexander Potapenko
2019-10-29 14:56       ` Qian Cai
2019-10-21  9:25   ` Petr Mladek
2019-10-29 13:59     ` Alexander Potapenko
2019-10-18  9:42 ` [PATCH RFC v1 20/26] kmsan: disable instrumentation of certain functions glider
2019-10-18  9:42 ` [PATCH RFC v1 21/26] kmsan: unpoison |tlb| in arch_tlb_gather_mmu() glider
2019-10-18  9:43 ` [PATCH RFC v1 22/26] kmsan: use __msan_memcpy() where possible glider
2019-10-18  9:43 ` [PATCH RFC v1 23/26] kmsan: unpoisoning buffers from devices etc glider
2019-10-18 15:27   ` Christoph Hellwig
2019-10-18 16:22   ` Matthew Wilcox
2019-10-29 14:45     ` Alexander Potapenko [this message]
2019-10-30 12:43       ` Alexander Potapenko
2019-10-18  9:43 ` [PATCH RFC v1 24/26] kmsan: hooks for copy_to_user() and friends glider
2019-10-18  9:43 ` [PATCH RFC v1 25/26] kmsan: disable strscpy() optimization under KMSAN glider
2019-10-18  9:43 ` [PATCH RFC v1 26/26] net: kasan: kmsan: support CONFIG_GENERIC_CSUM on x86, enable it for KASAN/KMSAN glider
2019-10-19  3:20   ` Randy Dunlap

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='CAG_fn=WYP1fqonfHM-RSNNpnFDe0AnonmgcuY_rf_7LXjKA9hw@mail.gmail.com' \
    --to=glider@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=dmitry.torokhov@gmail.com \
    --cc=dvyukov@google.com \
    --cc=edumazet@google.com \
    --cc=ericvh@gmail.com \
    --cc=hch@lst.de \
    --cc=linux-mm@kvack.org \
    --cc=martin.petersen@oracle.com \
    --cc=mst@redhat.com \
    --cc=tiwai@suse.com \
    --cc=tytso@mit.edu \
    --cc=vegard.nossum@oracle.com \
    --cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox