linux-kernel - Re: Cleaning up numbering for new x86 syscalls?

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] [day] [month] [year] [list]

Date:   Fri, 30 Nov 2018 23:25:09 +0000 (GMT)
From:   "Maciej W. Rozycki" <macro@...ux-mips.org>
To:     Bernd Petrovitsch <bernd@...rovitsch.priv.at>
cc:     Ingo Molnar <mingo@...nel.org>, Andy Lutomirski <luto@...nel.org>,
        X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
        Borislav Petkov <bp@...en8.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Tycho Andersen <tycho@...ho.ws>,
        Daniel Colascione <dancol@...gle.com>,
        Florian Weimer <fweimer@...hat.com>,
        Carlos O'Donell <carlos@...hat.com>,
        Rich Felker <dalias@...c.org>
Subject: Re: Cleaning up numbering for new x86 syscalls?

On Wed, 21 Nov 2018, Bernd Petrovitsch wrote:

> And yes, lots of stuff will not compile out of the box (especially if
> one uses a somewhat sane set of gcc options - not only -Wall -Wextra
> -Werror) but if one gets software to compile for i386 and x86_64,
> getting it to compile for x32 is a Friday afternoon job (more or less).
> And yes, there is enough hardware/systems out there that uses 64bit CPUs
> (for whatever reason - if only that one can't get a 32bit CPU for that
> board) but will never ever need more than 2-3 GB RAM .....

 The functionally equivalent 64-bit ILP32 MIPS n32 ABI has been around 
supported by Linux and the GNU toolchain for some 17 years now and people 
have been using it, so by now any sane piece of software that does not use 
handcoded assembly should work out of the box for the x86-64 x32 ABI as 
well.

 NB the important advantage of an LP64 ABI over an ILP32 ABI is the 
ability to mmap(2) files that exceed 4GiB in size (and in reality even 
smaller ones, as some user VM space is surely needed for other stuff), 
regardless of how much physical RAM is actually supported or has been 
installed.

 And these days even a web browser can easily overrun a 4GiB VM space. :(

 FWIW,

  Maciej