linux-kernel - Re: [PATCH v4] mm, kasan, kmsan: copy_from/to_kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANpmjNNPnEMBxF1-Lr_BACmPYxOTRa=k6Vwi=EFR=BED=G8akg@mail.gmail.com>
Date: Wed, 9 Oct 2024 22:34:43 +0200
From: Marco Elver <elver@...gle.com>
To: Andrey Konovalov <andreyknvl@...il.com>
Cc: Sabyrzhan Tasbolatov <snovitoll@...il.com>, akpm@...ux-foundation.org, bpf@...r.kernel.org, 
	dvyukov@...gle.com, glider@...gle.com, kasan-dev@...glegroups.com, 
	linux-kernel@...r.kernel.org, linux-mm@...ck.org, ryabinin.a.a@...il.com, 
	syzbot+61123a5daeb9f7454599@...kaller.appspotmail.com, 
	vincenzo.frascino@....com
Subject: Re: [PATCH v4] mm, kasan, kmsan: copy_from/to_kernel_nofault

On Wed, 9 Oct 2024 at 22:19, Andrey Konovalov <andreyknvl@...il.com> wrote:
[...]
> Please add a comment here explaining why we only check
> copy_to_kernel_nofault and not copy_from_kernel_nofault (is this
> because we cannot add KASAN instrumentation to
> copy_from_kernel_nofault?).

Just to clarify: Unless we can prove that there won't be any false
positives, I proposed to err on the side of being conservative here.
The new way of doing it after we already checked that the accessed
location is on a faulted-in page may be amenable to also KASAN
instrumentation, but you can also come up with cases that would be a
false positive: e.g. some copy_from_kernel_nofault() for a large
range, knowing that if it accesses bad memory at least one page is not
faulted in, but some initial pages may be faulted in; in that case
there'd be some error handling that then deals with the failure.
Again, this might be something that an eBPF program could legally do.
On the other hand, we may want to know if we are leaking random
uninitialized kernel memory with KMSAN to avoid infoleaks.

Only copy_to_kernel_nofault should really have valid memory, otherwise
we risk corrupting the kernel. But these checks should only happen
after we know we're accessing faulted-in memory, again to avoid false
positives.