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
| ||
|
Date: Tue, 16 Mar 2010 07:22:19 +1100 From: Benjamin Herrenschmidt <benh@...nel.crashing.org> To: David Miller <davem@...emloft.net> Cc: 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 Sun, 2010-03-14 at 22:54 -0700, David Miller wrote: > From: Benjamin Herrenschmidt <benh@...nel.crashing.org> > Date: Mon, 15 Mar 2010 16:18:33 +1100 > > > Or is there any good reason -not- to do that in glibc ? > > The whole point of syscall() is to handle cases where the C library > doesn't know about the system call yet. > > I think it's therefore very much "buyer beware". > > On sparc it'll never work to use the workaround you're proposing since > we pass everything in via registers. > > So arch knowledge will always need to be present in these situations. I'm not sure I follow. We also pass via register on powerpc, but the offset introduced by the sysno argument breaks register pair alignment which cannot be fixed up inside syscall(). However, if I change glibc's syscall to be something like #define syscall(sysno, args...) __syscall(0 /* dummy */, sysno, args) And make __syscall then do something like: mr r0, r4 mr r3, r5 mr r4, r6 mr r5, r7 mr r6, r8 .../... sc blr Then at least all that class of syscalls will be fixed. Of course this has to be in glibc arch code. I was merely asking if that was something our glibc folks would consider and whether somebody could think of a better solution :-) Cheers ,Ben. -- 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/
Powered by blists - more mailing lists