lkml.org 
[lkml]   [2013]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: ARM audit, seccomp, etc are broken wrt OABI syscalls
From
On Tue, Nov 5, 2013 at 2:36 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> [cc: some ARM people]
>
> After a bit of an adventure, I got QEMU working. (Linux 3.12's smc91x
> driver and qemu 1.6 don't get along. It would be great if some
> kernel.org page described a standard way to boot a modern Linux image
> on a modern QEMU version, but I digress.)

Yeah, I kept losing this battle too, and most recently switch to using
mmc emulation instead of the SCSI emulation (CONFIG_MMC=y, and qemu's
"sd" disk driver).

> The current state of affairs is unhealthy. I wrote a program
> (attached) that does 'svc $0x90002f' (silly GNU syntax for "Issue the
> getgid syscall in OABI"). The registers I program are:
>
> r0: 1
> r1: 2
> r2: 3
> r3: 4
> r4: 5
> r5: 6
>
> (i.e. the arguments are 1,2,3,4,5,6, although getgid ignores them)
>
> r7: 1
>
> (r7 is the EABI syscall register. On a kernel without OABI support,
> the immediate svc argument is ignored and syscall 1, i.e. _exit, will
> be invoked).

Just to clarify: without CONFIG_OABI_COMPAT, all OABI syscalls turn into _exit?

> Seccomp sees the registers as I set them (unsurprisingly) and it sees
> nr == 0x2f. It passes those values on to a SIGSYS handler, if one
> exists. This is, IMO, bad. The OABI and EABI argument passing
> conventions are *not* the same, and seccomp filters that check syscall
> argument values may be spoofable by using OABI calls.
>
> I suspect that audit, perf, ftrace, and maybe even ptrace are broken
> as well for exactly the same reason.
>
> I would argue that there are two reasonable fixes:
>
> 1. Set a different audit arch for OABI syscalls (e.g.
> AUDIT_ARCH_ARMOABI). That is, treat OABI syscall entries the same way
> that x86_64 treats int 80.
>
> 2. Leave the 0x900000 bits set in the syscall nr. That way OABI
> syscalls would look like a different set of syscalls on the same
> architecture. That is, treat OABI syscall entries kind of like x86_64
> treats x32 syscalls. (There's probably no reason to accept 0x900000 +
> N as an r7 value to cause 'svc 0' to invoke OABI syscall N, though.)
>
> 3. Unconditionally kill any process that makes an OABI syscall with
> seccomp enabled (because there should be no such programs). Eww.
>
> Options 1 and 2 are both break ABI, but I doubt that anythink cares.
> OABI is, AFAICT, mostly dead. That being said, even if nothing
> legitimate uses OABI, exploits against seccomp-using programs can
> certainly use OABI, so I think that this needs to be fixed somehow.
>
> Thoughts? I think I prefer option 1. I don't really want to make the
> change because my ARM assembly skills are lacking.

I would agree: option 1 seems cleanest of the 3. 3 is sort of like a
built-in automatic check for a mismatched arch, so maybe that works
better?

Alternatively, CONFIG_SECCOMP_FILTER could depend on
!CONFIG_OABI_COMPAT. That seems like the least work, given the desire
to kill OABI in the real world. (Though I would note that at least
Ubuntu's ARM kernels build with CONFIG_OABI_COMPAT; Chrome OS does
not.)

-Kees

--
Kees Cook
Chrome OS Security


\
 
 \ /
  Last update: 2013-11-06 01:41    [W:0.114 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site