linux-kernel - Re: ARM seccomp filters and EABI/OABI

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: <CAFLxGvwT+KDSTjJnd8HUhQivmpB3ZwjrXs1OxF8ctL7k6tN0Lw@mail.gmail.com>
Date:	Thu, 24 Oct 2013 21:55:57 +0200
From:	Richard Weinberger <richard.weinberger@...il.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	libseccomp-discuss@...ts.sourceforge.net,
	Will Drewry <wad@...omium.org>,
	Kees Cook <keescook@...omium.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: ARM seccomp filters and EABI/OABI

On Wed, Oct 23, 2013 at 11:02 PM, Andy Lutomirski <luto@...capital.net> 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.)  My basic question is: what happens
> if an OABI syscall happens?
>
> AFAICS, the syscall arguments for EABI are r0..r5, although their
> ordering is a bit odd*.  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?
>
> I'm a bit surprised to see that both the EABI and OABI ABIs show up as
> AUDIT_ARCH_ARM.
>
> 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.

Maybe this helps:
http://people.debian.org/~aurel32/qemu/armel/

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



-- 
Thanks,
//richard
--
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/