linux-kernel - Re: Can we drop upstream Linux x32 support?

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: <CAPmeqMoqNO2ps5tnGJX+Q7BgjdPKHt_vb3h+hDXC4=yth+r+dA@mail.gmail.com>
Date:   Fri, 14 Dec 2018 14:59:32 -0500
From:   Lance Richardson <lance.richardson.net@...il.com>
To:     Andy Lutomirski <luto@...capital.net>
Cc:     Rich Felker <dalias@...c.org>, Florian Weimer <fweimer@...hat.com>,
        Bernd Petrovitsch <bernd@...rovitsch.priv.at>,
        John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
        Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Borislav Petkov <bp@...en8.de>,
        Mike Frysinger <vapier@...too.org>,
        "H. J. Lu" <hjl.tools@...il.com>, x32@...ldd.debian.org,
        Arnd Bergmann <arnd@...db.de>,
        Will Deacon <will.deacon@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Can we drop upstream Linux x32 support?

My impression is it was mostly a desire to reuse existing x86_64 system calls
as much as possible without modification or additional compat layer work.

The 64-bit time requirement seems to have come from an lkml discussion, which
has quite a bit of interesting background about x32:
    https://lkml.org/lkml/2011/8/26/415
    https://lkml.org/lkml/2011/8/26/453


On Fri, Dec 14, 2018 at 2:05 PM Andy Lutomirski <luto@...capital.net> wrote:
>
>
>
> > On Dec 14, 2018, at 8:55 AM, Rich Felker <dalias@...c.org> wrote:
> >
> >> On Fri, Dec 14, 2018 at 05:38:33PM +0100, Florian Weimer wrote:
> >> * Rich Felker:
> >>
> >>> This is all useless (and wrong since tv_nsec is required to have type
> >>> long as part of C and POSIX, regardless of ILP32-vs-LP64; that's a bug
> >>> in glibc's x32).
> >>
> >> We should be able to fix standards if they prove unworkable in practice.
> >> In my opinion, if standards require complex solutions where an obvious
> >> and simple solution exists, then standards are wrong.
> >
> > The requirement doesn't mandate complex solutions. There's nothing
> > complex about tv_nsec being long. long is the smallest type that C
> > guarantees to be large enough to store the range of values, which is
> > forever fixed and can't grow (because the definition of "nano" prefix
> > is fixed :). The type has been long ever since the structure was
> > introduced, and its being long means that there's lots of (correct!)
> > code using %ld (e.g. ".%.9ld" to format results as a decimal without
> > using floating point approximations) to print it. There might also be
> > code taking pointers to it to pass to functions, etc.
> >
> > The only reason a "complex" need arises is that Linux did something
> > horribly wrong here, ignoring the specified type, when introducing an
> > obscure subarch that almost nobody uses. This kind of mistake is
> > becoming a theme in Linux (see also: msghdr). Application authors
> > should not have to pay the price for fixing this by retrofitting yet
> > another silly type like "snseconds_t" or something into programs to
> > accommodate the mistakes of x32.
> >
> >
>
> Does anyone know *why* Linux’s x32 has __kernel_long_t defined as long long?  I assume that this is where this bug, and most of the other bugs, came from.
>
> This may be silly, but the kernel could plausibly add a x32v2 where long is genuinely 32-bit, and then maybe we could drop the old x32 at some point.  From all the discussion so far, it seems like there really is some demand for ILP32, but it’s still not really clear that preserving compatibility with existing x32 binaries in the long run is critical.