linux-kernel - Re: [PATCH] x86: bring back rep movsq for user access on CPUs without ERMS

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-=wgrsfz4HmJE2fgdHrh-xUuVqk7t08=k2scz8Cgix0hBwg@mail.gmail.com>
Date:   Mon, 28 Aug 2023 11:24:52 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Mateusz Guzik <mjguzik@...il.com>
Cc:     linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
        bp@...en8.de
Subject: Re: [PATCH] x86: bring back rep movsq for user access on CPUs without ERMS

On Mon, 28 Aug 2023 at 11:04, Mateusz Guzik <mjguzik@...il.com> wrote:
>
> Other files do it (e.g., see __copy_user_nocache), but I have no
> strong opinion myself.

So the __copy_user_nocache() thing is a case of that second issue -
see my comment about "some sane visually sensible grouping" of the
numbers.

Look closer, and you'll notice that they aren't actually sequential.
They are of the form XY where the X is the grouping, and Y is the
local number within that grouping.

That case also comes with a fair amount of comments about each group
for the extable entries.

But yes, we also do have a number of thos e"sequential labels". See
for example arch/x86/lib/getuser.S, where we then end up having all
the exception handling at the end because it is mostly shared across
cases. It's ugly.

We also have a lot of ugly cases that probably shouldn't use numbers
at all, eg csum_partial(). I think that goes back to some darker age
when things like "assembly is so trivial that it doesn't need any
fancy explanatory labels for code" was ok.

See also arch/x86/lib/memmove_64.S for similar horrors. I wonder if it
is a case of "use compiler to get almost the right code, then massage
things manually". Nasty, nasty. That should use legible names, not
random numbers.

I also suspect some people really thought that the numbers need to be
unique, and just didn't know to use local numbering.

             Linus