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]

Date:   Thu, 13 Dec 2018 10:46:23 -0500
From:   Lance Richardson <lance.richardson.net@...il.com>
To:     olof@...om.net
Cc:     torvalds@...ux-foundation.org, luto@...nel.org, x86@...nel.org,
        linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
        hpa@...or.com, peterz@...radead.org, bp@...en8.de,
        fweimer@...hat.com, vapier@...too.org, hjl.tools@...il.com,
        dalias@...c.org, x32@...ldd.debian.org, arnd@...db.de,
        will.deacon@....com, catalin.marinas@....com
Subject: Re: Can we drop upstream Linux x32 support?

On Thu, Dec 13, 2018 at 9:39 AM Olof Johansson <olof@...om.net> wrote:
>
> On Tue, Dec 11, 2018 at 9:40 AM Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > On Mon, Dec 10, 2018 at 5:23 PM Andy Lutomirski <luto@...nel.org> wrote:
> > >
> > > I'm seriously considering sending a patch to remove x32 support from
> > > upstream Linux.  Here are some problems with it:
> >
> > I talked to Arnd (I think - we were talking about all the crazy ABI's,
> > but maybe it was with somebody else) about exactly this in Edinburgh.
> >
> > Apparently the main real use case is for extreme benchmarking. It's
> > the only use-case where the complexity of maintaining a whole
> > development environment and distro is worth it, it seems. Apparently a
> > number of Spec submissions have been done with the x32 model.
> >
> > I'm not opposed to trying to sunset the support, but let's see who complains..
>
> I'm just a single user. I do rely on it though, FWIW.
>
> I hadn't finished my benchmarking in Edinburgh, but for my new machine
> that does kernel builds 24/7, I ended up going with x32 userspace (in
> a container).
>
> Main reason is that it's a free ~10% improvement in runtime over
> 64-bit. I.e. GCC-as-a-workload is quite a bit faster as x32,
> supposedly mostly due to smaller D cache footprints (I ran out of
> cycles to tinker with back and forth perf data collection and settled
> down on just running it).
>
> Running classic 32-bit (i386? i686? whatever it's called) is about
> half as good. I.e. even then I get a ~5% performance win. Less than
> x32, but still better than 64-bit userspace.
>
>
> -Olof

I'm familiar with two embedded Linux systems using x32 ABI for the
following reasons:
   - Significant performance benefits over i386 ABI.
   - Smaller memory footprint than x86_64 (pointer-heavy data structures)
   - Large legacy software base with many ILP32 assumptions, much
     smaller effort to move to x32 than x86_64.

Some examples of (relatively minor) problems encountered with x32:
   - Time-related data type mismatch in socket options (fixed)
     https://patchwork.ozlabs.org/patch/904254/

   - Userspace overrun with select() (patch proposed)
     https://patchwork.kernel.org/patch/10245677/

   - glibc get_phys_pages() doesn't work correctly with x32
     (assumes that struct sysinfo fields are not wider than "long").

So, one small vote for keeping x32 with the hope that support for it
can continue to be improved...

   - Lance