linux-kernel - Re: [PATCH] arch/tile: new multi-core architecture for Linux

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:	Thu, 27 May 2010 10:35:06 -0400
From:	Chris Metcalf <cmetcalf@...era.com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-arch@...r.kernel.org
Subject: Re: [PATCH] arch/tile: new multi-core architecture for Linux

On 5/27/2010 10:11 AM, Arnd Bergmann wrote:
>>> > > I see. AFAICT, all other architectures don't need the wrapper in
>>> > > the 32 bit native case because they define the syscall calling
>>> > > conventions in libc such that they match what the kernel
>>> > > expects for a 64 bit argument (typically split in two subsequent
>>> > > argument slots). Would that work for you as well?
>>>       
>>
>> > Yes, we could override this in libc.  My assumption was that it was
>> > cleaner to do it in the kernel, since we support uclibc and glibc, and
>> > doing it in the kernel meant only doing it in one place.
>>     
> That's not the way I meant. There are two options how (any) libc can
> implement this:
> 1. the calling conventions for user function calls and for kernel
>    function calls are the same, so you don't need to do anything here.
> 2. the calling conventions are different, so you already need a wrapper
>    in user space for 64 bit arguments to split them up and you could
>    to that in exactly the way that the kernel expects to be called.
>   

The issue is that libc support for 64-bit operands on 32-bit platforms
tends to look like "syscall(foo64, arg1, LOW(arg2), HIGH(arg2))".  This
naturally passes the arguments in consecutive registers, for a
register-based calling convention like ours.  However, invoking
"foo64(arg1, (u64)arg2)" passes the u64 argument in the next consecutive
even/odd numbered pair of registers on our architecture.  Arguably this
notion of register alignment isn't particularly helpful, but we opted to
do it this way when we settled on the API.  The upshot is that to match
this, userspace needs to do "syscall(foo64, arg1, dummy, LOW(arg2),
HIGH(arg2))".  So we need to provide these dummy-argument versions of
the syscall wrappers to all the libcs that we use (currently uclibc,
glibc, and sometimes newlib).  Where the 64-bit argument falls naturally
on an even register boundary we don't need to provide any kernel stub.

Basically the scenario is your #2 above, but userspace already has an
implementation of the user-space wrapper in the generic code, and I'm
trying to avoid having to provide a tile-specific version of it.

For reference, here's readahead() in glibc (overridden to be a pure
syscall wrapper for 64-bit architectures):

ssize_t
__readahead (int fd, off64_t offset, size_t count)
{
  return INLINE_SYSCALL (readahead, 4, fd,
                         __LONG_LONG_PAIR ((off_t) (offset >> 32),
                                           (off_t) (offset & 0xffffffff)),
                         count);
}

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com

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