linux-kernel - Re: X32 psABI status

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:	Sun, 13 Feb 2011 07:37:28 -0800
From:	"H.J. Lu" <hjl.tools@...il.com>
To:	Florian Weimer <fw@...eb.enyo.de>
Cc:	x32-abi@...glegroups.com, GCC Development <gcc@....gnu.org>,
	GNU C Library <libc-alpha@...rceware.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: X32 psABI status

On Sun, Feb 13, 2011 at 7:21 AM, Florian Weimer <fw@...eb.enyo.de> wrote:
> * H. J. Lu:
>
>> On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer <fw@...eb.enyo.de> wrote:
>>> * H. J. Lu:
>>>
>>>>> Actually, I'm wondering if you can do the translation in user space.
>>>>> There already are 32-on-64 implementations in existence, without
>>>>> kernel changes (recent Hotspot, LuaJIT, and probably some more).
>>>>
>>>> Please check out the x32 kernel source and provide feedback.
>>>
>>> I still don't understand why you need a separate syscall table.  You
>>> should really be able to run on an unmodified amd64 kernel, in 64 bit
>>
>> That is done on purpose. x32 is designed for environments where the
>> current ia32 API is sufficient. You can think it as ia32 with register
>> extended to 64bit plus 8 more registers. Everything else is still 32bit.
>
> I think of it as amd64 where all the process memory happens to reside
> in the first 4 GB of address space, and pointers are stored as 32 bits
> (and you'd also reduce the size of longs because sizeof(long) !=
> sizeof(void *) will break too many programs).

That is what the processor sees in an x32 program.

> As I said, both LuaJIT and Hotspot are already using this model, with
> custom memory allocators and a user-space translation layers, so I
> still don't see what you get by changing the kernel.  LuaJIT has even
> implemented the amd64 ABI, so you can call C libraries from your
> 32-bit code.  (Note that LuaJIT uses 64-bit words to store 32-bit
> pointers with several tag bits, but it does so even on pure 32-bit
> platforms.)

They can continue to do so.

> If you want to make x32 closer to i386, I don't see the point.  Why
> would it be problematic if it was as close to i386 as, say, armel?
>

We are providing a 32bit API with 64bit registers. Current APIs support
either 32bit or 64bit.  I am not talking about pointer or long. I am talking
other types, like time_t, off_t, ..., defined by API.  Adding another API
is extremely difficult.

-- 
H.J.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/