linux-kernel - Re: [PATCH] arch: avr32: add dummy syscalls

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]

Message-ID: <20130204225343.GD4503@ZenIV.linux.org.uk>
Date:	Mon, 4 Feb 2013 22:53:44 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	H?vard Skinnemoen <hskinnemoen@...il.com>
Cc:	Hans-Christian Egtvedt <egtvedt@...fundet.no>,
	Matthias Brugger <matthias.bgg@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	David Howells <dhowells@...hat.com>,
	Dave Jones <davej@...hat.com>,
	Will Deacon <will.deacon@....com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] arch: avr32: add dummy syscalls

On Mon, Feb 04, 2013 at 08:34:47AM -0800, H?vard Skinnemoen wrote:

> > So it will use the gap in case of 32/32/64/32; the first two calls will
> > take index 0 and 64bit (r12 and r11 resp.), the third will take 3 and 4
> > (r9:r8) and the fourth will take 2 (r10).
> 
> Oh, cool. I guess I am wrong then. Thanks a lot for taking the time to
> figure this out, and sorry I misled you.
> 
> If someone's got the toolchain installed (which I don't, sorry), it
> should be relatively straightforward to verify this by looking at the
> disassembly of a call to a function with a similar prototype.

Ho-hum...
	* no regular syscalls for 32bit host have more than 192 (6*32) bits
worth of arguments (sys_syscall() takes up to 7*32, but that weirdness is
neither common nor desirable - it's compatibility-only stuff).
	* for C ABI on avr32 we have the following (sorted by the total size)
32bit  -> r12
32bit 32bit  -> r12 r11
64bit  -> r10:r11
32bit 32bit 32bit  -> r12 r11 r10
32bit 64bit  -> r12 r10:r11
64bit 32bit  -> r10:r11 r12  
32bit 32bit 32bit 32bit  -> r12 r11 r10 r9
32bit 32bit 64bit  -> r12 r11 r9:r8
32bit 64bit 32bit  -> r12 r10:r11 r9
64bit 32bit 32bit  -> r10:r11 r12 r9   
64bit 64bit  -> r10:r11 r9:r8   
32bit 32bit 32bit 32bit 32bit  -> r12 r11 r10 r9 r8
32bit 32bit 32bit 64bit  -> r12 r11 r10 r9:r8
32bit 32bit 64bit 32bit  -> r12 r11 r9:r8 r10
32bit 64bit 32bit 32bit  -> r12 r10:r11 r9 r8
32bit 64bit 64bit  -> r12 r10:r11 r9:r8
64bit 32bit 32bit 32bit  -> r10:r11 r12 r9 r8
64bit 32bit 64bit  -> r10:r11 r12 r9:r8  
64bit 64bit 32bit  -> r10:r11 r9:r8 r12  
32bit 32bit 32bit 32bit 32bit 32bit  -> r12 r11 r10 r9 r8 s
32bit 32bit 32bit 32bit 64bit  -> r12 r11 r10 r9 s:s
32bit 32bit 32bit 64bit 32bit  -> r12 r11 r10 r9:r8 s
32bit 32bit 64bit 32bit 32bit  -> r12 r11 r9:r8 r10 s
32bit 32bit 64bit 64bit  -> r12 r11 r9:r8 s:s
32bit 64bit 32bit 32bit 32bit  -> r12 r10:r11 r9 r8 s
32bit 64bit 32bit 64bit  -> r12 r10:r11 r9 s:s 
32bit 64bit 64bit 32bit  -> r12 r10:r11 r9:r8 s
64bit 32bit 32bit 32bit 32bit  -> r10:r11 r12 r9 r8 s
64bit 32bit 32bit 64bit  -> r10:r11 r12 r9 s:s
64bit 32bit 64bit 32bit  -> r10:r11 r12 r9:r8 s
64bit 64bit 32bit 32bit  -> r10:r11 r9:r8 r12 s
64bit 64bit 64bit  -> r10:r11 r9:r8 s:s
	* syscall ABI coincides with C one if neither r8 nor stack is used.
	* if C ABI would use r8 but not stack, syscall one uses r5 instead
of r8.
	* plain SYSCALL_DEFINE6 syscalls have
32bit 32bit 32bit 32bit 32bit 32bit  -> r12 r11 r10 r9 r5 r3
At least in one case the wrapper is missing for a wired syscall - sys_futex
is used as-is.
	* sync_file_range(2) is wired as
32bit 64bit 64bit 32bit  -> r12 r10:r11 r9:r5 r3
	* fadvise64_64(2) is missing a wrapper; same arguments as for
sync_file_range(), presumably with the same calling conventions
	* fanotify_mark(2) is not wired; presumably should be
32bit 32bit 64bit 32bit 32bit  -> r12 r11 r9:r5 r10 r3
	* sync_file_range2(2) (which is not going to be wired) and fallocate(2)
(which probably will) have the same argument types; calling conventions should
probably be something like
32bit 32bit 64bit 64bit  -> r12 r11 r9:r5 ?:?
libc function is going to have arguments in r12, r11, r9:r8 and in two
32bit words on stack, so libc-side glue should be
	r5 = r8
	r8 = __NR_fallocate
	r<something> = lower 32 bits of 'len' (sits on stack)
	r<something else> = upper 32 bits of 'len' (sits on stack)
Looks like it ought to be r10 and r3, if we want to keep the same set
of registers?

There are several argument type combinations that are not used at the moment,
but migth appear in the future; ones that have only one word passed on stack
should probably go the same way we deal with the SYSCALL_DEFINE6 ones, but
ones that spill *two* words on stack are really interesting.  In addition to
fallocate(2) [gap in r10, two words on stack], we have
32bit 32bit 32bit 32bit 64bit
32bit 64bit 32bit 64bit
64bit 32bit 32bit 64bit [gap in r8, two words on stack] and
64bit 64bit 64bit [gap in r12, two words on stack]

What calling conventions would we want for those?
--
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/