On Tue, Nov 5, 2013 at 2:36 PM, Andy Lutomirski <[email protected]> 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 ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ libseccomp-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libseccomp-discuss
