From: Marco Elver <elver@google.com>
To: Sabyrzhan Tasbolatov <snovitoll@gmail.com>
Cc: akpm@linux-foundation.org, andreyknvl@gmail.com,
bpf@vger.kernel.org, dvyukov@google.com, glider@google.com,
kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, ryabinin.a.a@gmail.com,
syzbot+61123a5daeb9f7454599@syzkaller.appspotmail.com,
vincenzo.frascino@arm.com
Subject: Re: [PATCH v2 1/1] mm, kasan, kmsan: copy_from/to_kernel_nofault
Date: Tue, 8 Oct 2024 11:27:26 +0200 [thread overview]
Message-ID: <ZwT6_gzV2evijOGK@elver.google.com> (raw)
In-Reply-To: <CACzwLxh1yWXQZ4LAO3gFMjK8KPDFfNOR6wqWhtXyucJ0+YXurw@mail.gmail.com>
On Tue, Oct 08, 2024 at 01:46PM +0500, Sabyrzhan Tasbolatov wrote:
> On Tue, Oct 8, 2024 at 1:32 PM Marco Elver <elver@google.com> wrote:
> >
> > On Sat, Oct 05, 2024 at 09:48PM +0500, Sabyrzhan Tasbolatov wrote:
> > > Instrument copy_from_kernel_nofault() with KMSAN for uninitialized kernel
> > > memory check and copy_to_kernel_nofault() with KASAN, KCSAN to detect
> > > the memory corruption.
> > >
> > > syzbot reported that bpf_probe_read_kernel() kernel helper triggered
> > > KASAN report via kasan_check_range() which is not the expected behaviour
> > > as copy_from_kernel_nofault() is meant to be a non-faulting helper.
> > >
> > > Solution is, suggested by Marco Elver, to replace KASAN, KCSAN check in
> > > copy_from_kernel_nofault() with KMSAN detection of copying uninitilaized
> > > kernel memory. In copy_to_kernel_nofault() we can retain
> > > instrument_write() for the memory corruption instrumentation but before
> > > pagefault_disable().
> >
> > I don't understand why it has to be before the whole copy i.e. before
> > pagefault_disable()?
> >
>
> I was unsure about this decision as well - I should've waited for your response
> before sending the PATCH when I was asking for clarification. Sorry
> for the confusion,
> I thought that what you meant as the instrumentation was already done after
> pagefault_disable().
I just did some digging and there is some existing instrumentation, but
not for what we want. The accesses in the loop on x86 do this:
copy_to_kernel_nofault:
#define __put_kernel_nofault(dst, src, type, err_label) \
__put_user_size(*((type *)(src)), (__force type __user *)(dst), \
sizeof(type), err_label)
and __put_user_size:
#define __put_user_size(x, ptr, size, label) \
do { \
__typeof__(*(ptr)) __x = (x); /* eval x once */ \
__typeof__(ptr) __ptr = (ptr); /* eval ptr once */ \
__chk_user_ptr(__ptr); \
switch (size) { \
case 1: \
__put_user_goto(__x, __ptr, "b", "iq", label); \
break; \
case 2: \
__put_user_goto(__x, __ptr, "w", "ir", label); \
break; \
case 4: \
__put_user_goto(__x, __ptr, "l", "ir", label); \
break; \
case 8: \
__put_user_goto_u64(__x, __ptr, label); \
break; \
default: \
__put_user_bad(); \
} \
instrument_put_user(__x, __ptr, size); \
} while (0)
which already has an instrument_put_user, which expands to this:
#define instrument_put_user(from, ptr, size) \
({ \
kmsan_copy_to_user(ptr, &from, sizeof(from), 0); \
})
So this is already instrumented for KMSAN, to check no uninitialized
memory is accessed - but that's only useful if copying to user space.
__put_kernel_nofault is "abusing" the same helper to copy to the kernel,
so adding explicit instrumentation as proposed still makes sense.
Thanks,
-- Marco
next prev parent reply other threads:[~2024-10-08 9:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-05 9:23 [PATCH] mm, kmsan: instrument copy_from_kernel_nofault Sabyrzhan Tasbolatov
2024-10-05 10:36 ` Marco Elver
2024-10-05 16:48 ` [PATCH v2 0/1] mm, kasan, kmsan: copy_from/to_kernel_nofault Sabyrzhan Tasbolatov
2024-10-05 16:48 ` [PATCH v2 1/1] " Sabyrzhan Tasbolatov
2024-10-08 8:31 ` Marco Elver
2024-10-08 8:46 ` Sabyrzhan Tasbolatov
2024-10-08 9:27 ` Marco Elver [this message]
2024-10-08 10:15 ` [PATCH v3] " Sabyrzhan Tasbolatov
2024-10-08 11:35 ` Marco Elver
2024-10-08 19:29 ` [PATCH v4] " Sabyrzhan Tasbolatov
2024-10-08 19:34 ` Marco Elver
2024-10-08 19:42 ` Sabyrzhan Tasbolatov
2024-10-09 21:39 ` Andrew Morton
2024-10-09 20:18 ` Andrey Konovalov
2024-10-09 20:34 ` Marco Elver
2024-10-10 13:11 ` [PATCH v5] " Sabyrzhan Tasbolatov
2024-10-10 21:39 ` Andrey Konovalov
2024-10-11 3:53 ` [PATCH v6] " Sabyrzhan Tasbolatov
2024-10-12 22:45 ` Andrey Konovalov
2024-10-15 11:05 ` Sabyrzhan Tasbolatov
2024-10-08 19:39 ` [PATCH v3] " Sabyrzhan Tasbolatov
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=ZwT6_gzV2evijOGK@elver.google.com \
--to=elver@google.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ryabinin.a.a@gmail.com \
--cc=snovitoll@gmail.com \
--cc=syzbot+61123a5daeb9f7454599@syzkaller.appspotmail.com \
--cc=vincenzo.frascino@arm.com \
/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.