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

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

Message-ID: <20130204013111.GX4503@ZenIV.linux.org.uk>
Date:	Mon, 4 Feb 2013 01:31:11 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Hans-Christian Egtvedt <egtvedt@...fundet.no>
Cc:	Matthias Brugger <matthias.bgg@...il.com>,
	Haavard Skinnemoen <hskinnemoen@...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@...r.kernel.org
Subject: Re: [PATCH] arch: avr32: add dummy syscalls

On Mon, Feb 04, 2013 at 12:30:47AM +0000, Al Viro wrote:
> On Mon, Feb 04, 2013 at 12:10:55AM +0000, Al Viro wrote:
> > On Sun, Jan 27, 2013 at 09:39:54PM +0100, Hans-Christian Egtvedt wrote:
> > > > If you are OK with going that way, I could probably put together patches doing
> > > > just that.  Note that for rt_sigsuspend/rt_sigreturn/sigaltstack the wrappers
> > > > are not needed at all - they can just use current_pt_regs() in syscall body.
> > > > IOW, all of syscall-stubs.S could be killed.
> > > 
> > > Nice, could you put together the preprocessor stuff in a patch? It would be
> > > great to not having to write a re-occuring stub for each syscall that has 6+
> > > arguments.
> > > 
> > > Thanks for looking at this.
> > 
> > Apologies about the delay...  One question: what's the AVR32 C ABI for
> > passing 64bit arguments?  The tricky bugger is sys_sync_file_range();
> > it takes (s32, s64, s64, u32) as arguments and if not any pair of
> > registers can be used to pass 64bit value, we have more serious trouble
> > there...
> 
> BTW, it's worse: both fadivse64 and fadvise64_64 are wired, neither of them
> has a wrapper and arguments are (s32, s64, u32, s32) and (s32, s64, s64, s32)
> resp.  The former is OK unless you have restrictions on register pairs that
> can be used for 64bit; the latter is past the 5-register limit no matter what,
> so the wrapper is really needed.

Unless I'm misreading ocavr32.pdf, that should be (R12, R10:R11, R9, R8) and
(R12, R10:R11, R9:R8, stack) resp., so fadvise64 doesn't need a wrapper, but
fadvise64_64 does.  And something like (s32, s32, s64, s64) would turn into
(R12, R11, R9:R8, stack, stack); AFAICS, we don't have anything that ugly...

Automating *that* is going to be interesting...  I've not given up, but it's
not going to be fun ;-/
--
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/