linux-kernel - Re: 64-syscall args on 32-bit vs syscall()

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 15 Mar 2010 14:44:49 +0100
From:	Ralf Baechle <ralf@...ux-mips.org>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	David Miller <davem@...emloft.net>, linux-arch@...r.kernel.org,
	linux-kernel@...r.kernel.org, kernel@...savvy.com,
	drepper@...hat.com, torvalds@...ux-foundation.org,
	munroesj@...ux.vnet.ibm.com
Subject: Re: 64-syscall args on 32-bit vs syscall()

On Mon, Mar 15, 2010 at 04:18:33PM +1100, Benjamin Herrenschmidt wrote:

> On Sun, 2010-03-14 at 22:06 -0700, David Miller wrote:
> > From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
> > Date: Mon, 15 Mar 2010 15:48:13 +1100
> > 
> > > As it is, any 32-bit app using syscall() on any of the syscalls that
> > > takes 64-bit arguments will be broken, unless the app itself breaks up
> > > the argument, but the the order of the hi and lo part is different
> > > between BE and LE architectures ;-)
> > 
> > I think it is even different on the same endian architectures,
> > f.e. mips I think.

MIPS passes arguments in the endian order that is low/high for little
endian rsp high/low for big endian.

> > There is no way to do this without some arch specific code
> > to handle things properly, really.
> 
> Right, but to what extent ? IE. do we always need the callers using
> syscall() directly to know it all, or can we to some extent handle some
> of it inside glibc ?
> 
> For example, if powerpc glibc is fixed so that syscall() takes a 64-bit
> first argument (or calls via some macro to add a dummy 32-bit argument),
> the register alignment will be preserved, and things will work just
> fine.
> 
> IE. It may not fix all problems with all archs, but in this case, it
> will fix the common cases for powerpc at least :-) And any other arch
> that has the exact same alignment problem.
> 
> Or is there any good reason -not- to do that in glibc ?

Syscall is most often used for new syscalls that have no syscall stub in
glibc yet, so the user of syscall() encodes this ABI knowledge.  If at a
later stage syscall() is changed to have this sort of knowledge we break
the API.  This is something only the kernel can get right.

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