linux-kernel - Re: [GIT PULL] RISC-V Fixes for 5.7-rc5

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: <mhng-a0b97369-68df-4c33-ab10-28a5d3950b5e@palmerdabbelt-glaptop1>
Date:   Mon, 11 May 2020 15:02:42 -0700 (PDT)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
CC:     schwab@...e.de, linux-riscv@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject:     Re: [GIT PULL] RISC-V Fixes for 5.7-rc5

On Mon, 11 May 2020 12:04:09 PDT (-0700), Linus Torvalds wrote:
> On Mon, May 11, 2020 at 1:13 AM Andreas Schwab <schwab@...e.de> wrote:
>>
>> On Mai 09 2020, Linus Torvalds wrote:
>>
>> > glibc depending on kernel version is WRONG. It's bogus. You can't do
>> > feature detection based on kernel version, it's fundamentally broken.
>> >
>> > So I really would prefer to see glibc fixed not to do that stupid
>> > thing, instead of adding pointless vdso notes to the kernel.
>>
>> I'm not aware of any discussion or bug report on this issue.  Any
>> pointer?
>
> We've discussed it informally several times, but that really is just
> "I remember mentioning this before" than anything else.
>
> Basically, testing kernel versions is pretty much always a bug. You
> _will_ get it wrong, sometimes spectacularly (we've had programs
> literally break when the major number changed, because they only
> checked the minor number).
>
> Other times you'll get it wrong in subtler ways - testing for features
> by version number is wrong, if that feature is then disabled by a
> config option (a lot of new kernel features work that way).
>
> Or, the already mentioned "distros often port back features to their
> older kernels". The latest example of that is Wireguard being ported
> back to Ubuntu 20.04 - using kernel version 5.4, even though WG was
> actually upstreamed in 5.6.
>
> So the whole "look at kernel version to determine if it does X" is
> simply fundamentally wrong.
>
> Why is glibc doing it in the first place? Is it some historical thing
> that is simply irrelevant on RISC-V simply because RISC-V doesn't have
> that kind of history, perhaps?

I don't know if Andreas had something else in mind, but there's actually a
RISC-V specific reason we _do_ need this: the 64-bit time_t conversion.
Essentially what happened is that I screwed up by merging the rv32 Linux port
before the rv32 glibc port.  As part of the rv32 upstreaming process we
realized that it would be better in the long term to just drop the 32-bit
time_t support from the kernel, but at that point we already had the Linux UABI
defined.

We ended up changing the user ABI on 32-bit systems as of d4c08b9776b3 ("riscv:
Use latest system call ABI").  We didn't have any rv32 userspace at that time
(and we still don't have glibc or any Linux capable hardware), so we figured it
would be OK to break the rules and change the ABI.  The obvious result is that
32-bit userspace won't work with old kernels, so I'd assumed this was being
used to quickly sanity check the kernel.

Andreas would know better than I do, though, as  I don't really do much glibc
stuff any more.

>
>                  Linus