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:57:36 -0800
From:	"H.J. Lu" <hjl.tools@...il.com>
To:	"Maciej W. Rozycki" <macro@...ux-mips.org>
Cc:	Florian Weimer <fw@...eb.enyo.de>, 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:43 AM, Maciej W. Rozycki <macro@...ux-mips.org> wrote:
> On Sun, 13 Feb 2011, Florian Weimer wrote:
>
>> >> 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
>> mode.  This would imply that tools like strace don't need any porting
>> at all (you could just use the amd64 version), and even GDB would
>> mostly worked unchanged.
>
>  For the record -- I suggested a similar approach for n32 MIPS too (back
> when it was on the table), but people rejected it deciding it was easier
> for them to add a separate syscall table (for a change).  It was perhaps
> even more surprising as any MIPS 32-bit user pointer is a valid 64-bit one
> too (I suspect this is also the case with x86-64) and any simple type,
> including pointers and the "long long" type (such as used with lseek64(2),
> etc.) goes into a single 64-bit register or stack slot with both ABIs, so
> any conversion layer (boundary checks or whatever; structures can be
> sorted out with padding) in libc would be pretty thin.

x32 is the same 64bit kernel interface for system calls which takes 64bit
arguments.  You can pass either 32bit or 64bit value to them.

-- 
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ