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]

Date:	Wed, 17 Mar 2010 19:56:19 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Ulrich Drepper <drepper@...hat.com>
Cc:	munroesj@...ibm.com, "H. Peter Anvin" <hpa@...or.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 Tue, 2010-03-16 at 22:52 -0700, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 03/16/2010 05:31 PM, Benjamin Herrenschmidt wrote:
> > My proposal is purely a change to the syscall()
> > function, nothing else. No kernel change, no ABI change, no change to
> > the way glibc normally calls syscalls internally, etc...
> 
> How can this be?  People are today actively working around the problem
> of 64-bit arguments.  You have to break something since you cannot
> recognize these situations.

Ok, so I -may- be missing something, but I believe this won't break
anything:

 - You keep the existing syscall() exported by glibc for binary
compatibility

 - You add a new __syscall() (or whatever you want to name it) that adds
a dummy argument at the beginning, and whose implementation shifts
everything by 2 instead of 1 argument before calling into the kernel

 - You define in unistd.h or whatever is relevant, a macro that does:

#define syscall(__sysno, __args..) __syscall(0, _sysno, __args)

I believe that should cover it, at least for powerpc, possibly for other
archs too though as I said, I may have missed something there.

IE. Whether your app writes:

	syscall(SYS_foo, my_64bit_arg);

Or

	syscall(SYS_foo, (u32)(my_64bit_arg >> 32), (u32)(my_64bit_arg));

Both should still work with the new approach and end up doing the right
thing.

Hence, apps that use the first form today because it works on x86 would
end up working at least on powerpc where they would have been otherwise
broken unless they used some arch specific #ifdef to do the second form.
 
>   And since it became meanwhile clear that
> there is no way to "fix" all archs magically I really don't want to
> introduce anything.  There are mechanisms in place to abstract out some
> of the issues.  And for the rest, well, if you're using syscalls
> directly you already have to encoded lowlevel knowledge.  One more bit
> doesn't hurt.  It's not as if this happens every day.

It doesn't happen everyday. However, if my proposal ends up fixing a
bunch of cases where it does without breaking anything, then I suppose
it's worth considering, though as I said, it's possible that I miss some
subtlety here in which case I'd be glad to stand corrected :-)

Cheers,
Ben.
  
> - -- 
> ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkugbhsACgkQ2ijCOnn/RHQzlACeMp0UK2jZuZOgXhJjB8Z9p4kh
> rCoAn0zaJqFYV9tQ0Ct49Mprfa0O5iKh
> =71la
> -----END PGP SIGNATURE-----


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