On Thu, Oct 24, 2013 at 12:11 PM, Paul Moore <[email protected]> wrote: > 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.
The original ARM seccomp patch had two SECCOMP_ARCH entries, but it was a mistake as it was really a description of endianness: https://lkml.org/lkml/2012/11/5/273 I also got the impression from another discussion I can't find that when seccomp does its checks, the syscall offset has already been dealt with. The best I could find discussing this was: https://lkml.org/lkml/2012/11/1/383 >> 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. Yeah, I set up an ARM emulator via QEMU. It is very slow, but it at least gets me somewhere with testing when I don't have a real ARM device handy. I followed the Debian ARM qemu instructions. -Kees -- Kees Cook Chrome OS Security ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ libseccomp-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libseccomp-discuss
