linux-kernel - Re: X32 project status update

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]

Message-ID: <4DD80A91.5070302@intel.com>
Date:	Sat, 21 May 2011 11:55:13 -0700
From:	"H. Peter Anvin" <h.peter.anvin@...el.com>
To:	x32-abi@...glegroups.com
CC:	"H.J. Lu" <hjl.tools@...il.com>, Arnd Bergmann <arnd@...db.de>,
	GCC Development <gcc@....gnu.org>,
	GNU C Library <libc-alpha@...rceware.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: X32 project status update

On 05/21/2011 09:27 AM, H.J. Lu wrote:
> On Sat, May 21, 2011 at 8:34 AM, H.J. Lu <hjl.tools@...il.com> wrote:
>> On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann <arnd@...db.de> wrote:
>>> On Saturday 21 May 2011 17:01:33 H.J. Lu wrote:
>>>> This is the x32 project status update:
>>>>
>>>> https://sites.google.com/site/x32abi/
>>>>
>>>
>>> I've had another look at the kernel patch. It basically
>>> looks all good, but the system call table appears to
>>> diverge from the x86_64 list for no (documented) reason,
>>> in the calls above 302. Is that intentional?
>>>
>>> I can see why you might want to keep the numbers identical,
>>> but if they are already different, why not use the generic
>>> system call table from asm-generic/unistd.h for the new
>>> ABI?
>>
>> We can sort it out when we start merging x32 kernel changes.
>>
> 
> Peter, is that possible to use the single syscall table for
> both x86-64 and x32 system calls? Out of 300+ system
> calls, only 84 are different for x86-64 and x32.  That
> is additional 8*84 == 672 bytes in syscall table.
> 

Sort of... remember we talked about merging system calls at the tail
end?  The problem with that is that some system calls (like read()!)
actually are different system calls in very subtle situations, due to
abuse in some subsystems of the is_compat() construct.  I think that may
mean we have to have an unambiguous flag after all...

Now, perhaps we can use a high bit for that and mask it before dispatch,
then we don't need the additional table.  A bit of a hack, but it should
work.

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