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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <1268928480.19726.123.camel@spokane1.rchland.ibm.com>
Date:	Thu, 18 Mar 2010 11:08:00 -0500
From:	Steven Munroe <munroesj@...ux.vnet.ibm.com>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Ulrich Drepper <drepper@...hat.com>, munroesj@...ibm.com,
	David Miller <davem@...emloft.net>, ralf@...ux-mips.org,
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
	kernel@...savvy.com, torvalds@...ux-foundation.org
Subject: Re: 64-syscall args on 32-bit vs syscall()

On Thu, 2010-03-18 at 09:58 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2010-03-17 at 13:53 -0700, H. Peter Anvin wrote:
> > > Yeah, whatever, I don't mind what technique you use for the
> > versionning,
> > > ultimately, if the approach works, we can look at those details :-)
> > We
> > > -do- need the macro to strip the dummy argument though, unless we
> > use
> > > a slightly different technique which is to make the __sysno argument
> > > itself 64-bit, which works as well I believe.
> > >
> > 
> > It seems cleaner to do it that way (with a 64-bit sysno arg.) 
> 
> Right. Now if we can get Ulrich to actually put 2 and 2 together and
> admit that it actually works without breaking anything existing (at
> least for my arch but I wouldn't be surprised if that was the case for
> others), I would be even happier :-)
> 
> Steve, any chance you can cook up a glibc patch to test with ? Maybe
> making it powerpc specific for now ?
> 

Do what declare __sysno as long long? The current prototype is in
unistd.h:

#ifdef __USE_MISC
/* Invoke `system call' number SYSNO, passing it the remaining
arguments.
   This is completely system-dependent, and not often useful.

   In Unix, `syscall' sets `errno' for all errors and most calls return
-1
   for errors; in many systems you cannot pass arguments or get return
   values for all system calls (`pipe', `fork', and `getppid' typically
   among them).

   In Mach, all system calls take normal arguments and always return an
   error code (zero for success).  */
extern long int syscall (long int __sysno, ...) __THROW;

#endif	/* Use misc.  */

Changing this would be an ABI change and would have to be versioned. It
would effect any one using syscall not just SYS_fallocate.

the question is do programmers in practice include unistd.h when they
use syscall.

If the changed prototype is not in scope then the 1st parm (__sysno)
defaults to int and is passed in on r3 which gets moved to r0.

If the changed syscall prototype is in scope then then _sysno would be
passed in r3/r4 (r3 would be 0 would be passed to r0 and the actual
system number would be in r4 and passed to the kernel in r3)

which behavior do you want? which (incorrect behavior compiled into
existing codes do you want to support?

Do you want syscall.S for PPC32 to change to match the changed
prototype? It will have to be be versioned and the new prototype will
only be available in future releases of GLIBC. Existing applications
will bind to the old ABI and get the old behavior.

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