Re: [libseccomp-discuss] ARM seccomp filters and EABI/OABI
From: Kees Cook
Date: Wed Oct 30 2013 - 13:19:40 EST
On Thu, Oct 24, 2013 at 12:11 PM, Paul Moore <pmoore@xxxxxxxxxx> 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:
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:
>> 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
> 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.
Chrome OS Security
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/