ABIs, syscall tables, and the AUDIT_ARCH_* defines

Paul Moore
2013-10-29T21:28:59Z

Hello all,

I've been dealing with the AUDIT_ARCH_* defines, different ABIs and syscall
tables a fair amount lately as part of libseccomp[1] and a little birdie
thought it might be a good idea to post something to the Linux audit list.

So here we go. I'll try to be brief.

First off, if you already understand that in some cases a given AUDIT_ARCH_*
value can represent multiple ABIs and you are fine with that, feel free to hit
delete now and move on. I'm not trying to argue that what audit is currently
doing is right or wrong, just trying to make things perhaps a bit more clear.

The core issue is that AUDIT_ARCH alone can not be used to specify a given
ABI, all the AUDIT_ARCH value can tell you is the syscall table; which in it's
defense, is all the original source comments claim. However, if you want to
be able to identify an ABI, I'm finding that you need both the AUDIT_ARCH
value and the syscall number (from my experience this hold true for x86,
x86_64, x32, ARM OABI, and ARM EABI, I can't speak for others at this point).

Take x86_64 and x32 as an example (think of x32 as a 32-bit version of
x86_64). Both x32 and x86_64 use the AUDIT_ARCH_X86_64 value and general
calling convention, but they have a different syscall table. The x32 syscall
table is the same as the x86_64 syscall table but with a 0x40000000 offset,
e.g. on x86_64 the write() syscall is 0x01 but on x32 write() is 0x40000001.
The 32-bit ARM ABIs are similar in that the EABI and OABI ABIs share the same
AUDIT_ARCH_ARM value and have similar syscall tables, separated by a 0x900000
offset. With ARM there is some additional oddities between OABI and EABI with
respect to syscall arguments, but I'm still figuring that out myself and it
wouldn't be right for me to talk about that here.

There ya go, hopefully this helps somewhat. If you have any questions I'll do
my best to try and answer them.

-Paul

[1] http://sourceforge.net/projects/libseccomp

--
paul moore
security and virtualization @ redhat