Message-ID: <1393414.jBrsFW4xK5@sifl>
Date:	Thu, 24 Oct 2013 15:11:19 -0400
From:	Paul Moore <pmoore@...hat.com>
To:	libseccomp-discuss@...ts.sourceforge.net
Cc:	Andy Lutomirski <luto@...capital.net>,
	Will Drewry <wad@...omium.org>,
	Kees Cook <keescook@...omium.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [libseccomp-discuss] ARM seccomp filters and EABI/OABI

On Wednesday, October 23, 2013 02:02:00 PM Andy Lutomirski wrote:
> I'm looking at the seccomp code, the ARM entry code, and the
> syscall(2) manpage, and I'm a bit lost.  (The fact that I don't really
> speak ARM assembly doesn't help.)

I suspect Kees, and perhaps Will, will be able to provide the best answers, 
but my thoughts are below.

> My basic question is: what happens if an OABI syscall happens?

Well, libseccomp doesn't support ARM OABI and since all the new ARM stuff is 
EABI I don't think there is much reason to worry about OABI.  I know this 
doesn't answer your question, but perhaps this provides some context.

> AFAICS, the syscall arguments for EABI are r0..r5, although their
> ordering is a bit odd*.

Hmmm, that could complicate things a bit - do you know if they are put in a 
more "standard" order by the time they are accessed in seccomp_bpf_load() via 
task_pt_regs()?  If not, we likely need to come up with some special handling 
in libseccomp to account for this.

> For OABI, r6 seems to play some role, but I'm
> lost as to what it is.  The seccomp_bpf_load function won't load r6,
> so there had better not be anything useful in there...  (Also, struct
> seccomp_data will have issues with a seventh "argument".)
> 
> But what happens to the syscall number?  For an EABI syscall, it's in
> r7.  For an OABI syscall, it's in the swi instruction and gets copied
> to r7 on entry.  If a debugger changes r7, presumably the syscall
> number changes.
> 
> Oddly, there are two different syscall tables.  The major differences
> seem to be that some of the OABI entries have their argument order
> changed.  But there's also a magic constant 0x900000 added to the
> syscall number somewhere -- is it reflected in _sigsys._syscall?  Is
> it reflected in ucontext's r7?

Thankfully, I've been able to ignore most of this.

> I'm a bit surprised to see that both the EABI and OABI ABIs show up as
> AUDIT_ARCH_ARM.

Yeah, the usage of AUDIT_ARCH_* is not really ideal for seccomp.  There are 
similar issues with x32; not quite as bad as with ARM, but still ... 

> Can any of you shed some light on this?  I don't have an ARM system I
> can test on, but if one of you can point me at a decent QEMU image, I
> can play around.

I know Kees had one at one point, although I remember him commenting that it 
was painfully slow under QEMU.

> For reference, I'm working on userspace code to decode a TRAP and
> eventually to allow syscall emulation (either by emulating the syscall
> inside the signal handler and setting the return value or (egads!) by
> changing the syscall and restarting it -- the latter is probably
> impossible if the original syscall came in through OABI and may be
> generally impossible if userspace expects any of the argument
> registers to be preserved).
> 
> 
> * I think that a syscall with signature long func(int a, long long b,
> int c, int d, int e) ends up with c in r1 and b in r2/r3.  The
> syscall(2) manpage appears to be entirely wrong.

-- 
paul moore
security and virtualization @ redhat

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