linux-kernel - Re: [PATCH v2] 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-=wjrvn+J=z0_schGSROK0HCK-xs4wgky6pRKy7kVLhDeLg@mail.gmail.com>
Date:   Sun, 3 Sep 2023 12:14:46 -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 v2] x86: bring back rep movsq for user access on CPUs
 without ERMS

On Sun, 3 Sept 2023 at 11:49, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Why _is_ glibc doing that thing?

Oh, I think I may see where the confusion may come from.

The glibc people found a "__NR_newfstatat", and thought it was a newer
version of 'stat', and didn't find any new versions of the basic
stat/fstat/lstat functions at all. So they thought that everything
else was implemented using that 'newfstatat()' entrypoint.

But on x86-64 (and most half-way newer architectures), the regular
__NR_stat *is* that "new" stat.

After all, it was only "new" in 1992, long before x86-64 even existed.

So maybe somebody noticed that "__NR_newfstatat" is the only system
call number that has that "new" in the stat name, and didn't realize
that that was just an odd naming thing for strange historical reasons.

The relevant system call numbers are

  #define __NR_stat 4
  #define __NR_fstat 5
  #define __NR_lstat 6
  #define __NR_newfstatat 262
  #define __NR_statx 332

and the numbering very much is about when they were added.

And yes, that "new" in "newfstatat" is misleading, it's the same
'struct stat' as those stat/fstat/lstat system calls (but not the
'statx' one, that has 'struct statx', of course).

On x86-32, which has that extra decade of history, you end up with

  #define __NR_oldstat 18
  #define __NR_oldfstat 28
  #define __NR_oldlstat 84
  #define __NR_stat 106
  #define __NR_lstat 107
  #define __NR_fstat 108
  #define __NR_stat64 195
  #define __NR_lstat64 196
  #define __NR_fstat64 197
  #define __NR_fstatat64 300
  #define __NR_statx 383

where 106-108 are those "new" stat calls.  And then the stat64 ones
are the "new new" ones and the only version that was relevant by the
time we got the 'at()' version.

              Linus