linux-kernel - Re: [RFC] raw_copy_from

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: <CAHk-=wirA7zJJB17KJPCE-V9pKwn8VKxXTeiaM+F+Sa1Xd2SWA@mail.gmail.com>
Date:   Sun, 19 Jul 2020 12:34:11 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     linux-arch <linux-arch@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] raw_copy_from_user() semantics

On Sun, Jul 19, 2020 at 12:28 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> I think we should try to get rid of the exact semantics.

Side note: I think one of the historical reasons for the exact
semantics was that we used to do things like the mount option copying
with a "copy_from_user()" iirc.

And that could take a fault at the end of the stack etc, because
"copy_mount_options()" is nasty and doesn't get a size, and just
copies "up to 4kB" of data.

It's a mistake in the interface, but it is what it is. But we've
always handled the inexact count there anyway by originally doing byte
accesses, and at some point you optimized it to just look at where
page boundaries might be..

I think that was the only truly _valid_ case of "we actually copy data
from user space, and we might need to handle a partial case", and
exactly because of that, it had already long avoided the whole "assume
copy_from_user gives us byte-accurate data before the fault".

              Linus