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:   Wed, 12 Dec 2018 09:01:47 -0500
From:   Rich Felker <dalias@...c.org>
To:     Steven Newbury <steve@...wbury.org.uk>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        macro@...ux-mips.org, tg@...bsd.de, luto@...nel.org, arnd@...db.de,
        s@...oud.org, catalin.marinas@....com, fweimer@...hat.com,
        glaubitz@...sik.fu-berlin.de, christian.brauner@...onical.com,
        hjl.tools@...il.com, hpa@...or.com
Subject: Re: Can we drop upstream Linux x32 support?

On Wed, Dec 12, 2018 at 09:12:34AM +0000, Steven Newbury wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> First off I'd like to request: Please don't break my userspace!
> 
> I have a number of systems running with x32-abi as native.  They work
> well, I've no want or desire to upgrade their memory or CPUs to make
> keep them working as well as they do now.  Let alone the hassle of
> having to redeploy with a completely different ABI.
> 
> 
> I've been working on getting as much userspace as I can working with
> x32 since it first became somewhat usable, I've sent patches upstream
> and pushed to encourage projects to write portable code.  Sometimes
> that has meant just little tweaks to build systems, or sometimes
> disabling asm where I consider it isn't worth the effort of making it
> work.  For other projects I've converted the asm or even in some cases
> got the JIT working, mozjs17 for example.
> 
> So I'm both a user and a developer.
> 
> Breaking support for x32 would be really bad for me, but if I'm the
> only one using it I suppose I can't really justify it being kept on
> that basis.  I know CERN has sucessfully experimented with it over the
> years though, so I wouldn't be surprised if there are other users
> hiding out there.
> 
> I can't help but wonder if it wouldn't make more sense to drop x86
> support from long mode than x32.  AMD64 x86 support was always intended
>  as a compatibility feature, I very much doubt there are more people
> out there using an x86 native userspace on a 64 bit kernel than there

I am. The only reason I'm using a 64-bit kernel with it is to get the
full 4GB address space for userspace rather than just 3GB. I suspect
there are more users like me than like you.

Unlike x32, i386 is actually widely supported and works, and achieves
most of the benefits of x32, but with marginally worse performance due
to register scarcity, lack of native 64-bit arithmetic, bad function
call ABI, and bad PC-relative addressing. For applications that aren't
performance sensitive it's the right choice for shipping static
binaries, especially if they may be memory-hungry, since it works on
pretty much any box.

> are native x32 users.  x86 support could be implemented via KVM and/or
> qemu-user.  There is no reason to keep the extra complexity in the
> kernel for what is effectively an emulation layer anyway.

qemu-user is a non-solution. Not only does it result in being much
slower and using more resources than just running a 64-bit userspace
(defeating the purpose); it's also incapable of correctly emulating
lots of corner cases. I've never been able to get it to work with
thread cancellation, and doing so is fundamentally hard because it
would require heavy emulation of signals rather than passing them
through.

Rich