* ABIs, syscall tables, and the AUDIT_ARCH_* defines
@ 2013-10-29 21:28 Paul Moore
2013-10-29 21:29 ` Eric Paris
0 siblings, 1 reply; 3+ messages in thread
From: Paul Moore @ 2013-10-29 21:28 UTC (permalink / raw)
To: linux-audit
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: ABIs, syscall tables, and the AUDIT_ARCH_* defines
2013-10-29 21:28 ABIs, syscall tables, and the AUDIT_ARCH_* defines Paul Moore
@ 2013-10-29 21:29 ` Eric Paris
2013-10-29 21:56 ` Paul Moore
0 siblings, 1 reply; 3+ messages in thread
From: Eric Paris @ 2013-10-29 21:29 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit
On Tue, 2013-10-29 at 17:28 -0400, Paul Moore wrote:
> 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.
I guess a good question is "is that right" ?
#define AUDIT_ARCH_X86_64 (EM_X86_64|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE)
Would we not be better off with a:
#define AUDIT_ARCH_X32 (EM_X86_64|__AUDIT_ARCH_LE) ?
Do x86_64 and x32 share the same syscall entry code? Is there where the
AUDIT_ARCH_X86_64 comes from? Is this similar for ARM? Right now, the
only thing we have is:
#define AUDIT_ARCH_ARM (EM_ARM|__AUDIT_ARCH_LE)
#define AUDIT_ARCH_ARMEB (EM_ARM)
Is this enough? Should we add more? I'm way way way more ARM idiotic
than I am about x86_64. I know the ARM people at least told us that ARM
wasn't going to work right with what we have today... So they added to
the audit Kconfig:
depends on AUDIT && (X86 || PPC || S390 || IA64 || UML || SPARC64 ||
SUPERH || (ARM && AEABI && !OABI_COMPAT))
Is fixing this with differentiated AUDIT_ARCH flags even possible? Am I
just talking out of my bum?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: ABIs, syscall tables, and the AUDIT_ARCH_* defines
2013-10-29 21:29 ` Eric Paris
@ 2013-10-29 21:56 ` Paul Moore
0 siblings, 0 replies; 3+ messages in thread
From: Paul Moore @ 2013-10-29 21:56 UTC (permalink / raw)
To: Eric Paris; +Cc: linux-audit
On Tuesday, October 29, 2013 05:29:41 PM Eric Paris wrote:
> On Tue, 2013-10-29 at 17:28 -0400, Paul Moore wrote:
> > 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.
>
> I guess a good question is "is that right" ?
>
> #define AUDIT_ARCH_X86_64 (EM_X86_64|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE)
>
> Would we not be better off with a:
>
> #define AUDIT_ARCH_X32 (EM_X86_64|__AUDIT_ARCH_LE) ?
If you look at the libseccomp code, that is exactly how we define
SCMP_ARCH_X32. To me it makes sense.
However, I think it may already be too late to change things in the kernel.
Support for x32 has been in mainline for a while now and userspace has already
had to deal with it; changing to AUDIT_ARCH_X32, while arguably The Right
Thing To Do, would likely involve userspace breakage. At least it would break
libseccomp :)
> Do x86_64 and x32 share the same syscall entry code?
I can't say off the top of my head, but if I had to guess, I would say yes.
UPDATE: I took a quick peek and while I'm not well versed on the syscall entry
code, it does appear that they share most of the important bits.
> Is there where the AUDIT_ARCH_X86_64 comes from?
I believe so. Depending on the state of CONFIG_AUDITSYSCALL it either gets
passed directly as the first argument to __audit_syscall_entry() in entry_64.S
or via syscall_trace_enter() which once again just uses AUDIT_ARCH_X86_64.
In both cases it should be possible to set it to a new AUDIT_ARCH_X32, but my
previous concerns about userspace breakage still apply.
> Is this similar for ARM? Right now, the only thing we have is:
>
> #define AUDIT_ARCH_ARM (EM_ARM|__AUDIT_ARCH_LE)
> #define AUDIT_ARCH_ARMEB (EM_ARM)
>
> Is this enough? Should we add more?
No idea really, I'm still getting up to speed on ARM. Personally, ARM OABI is
really weird and considering that most everything is EABI now, I don't think
I'm ever going to support ARM OABI in libseccomp.
The answer might not be as easy for audit since the kernel technically already
supports ARM OABI, but I'm guessing that if you haven't head anyone shouting
at you by now you might not have to worry too much about it.
> I'm way way way more ARM idiotic than I am about x86_64.
Me too. Although the more I learn about ARM the more it scares me.
> I know the ARM people at least told us that ARM wasn't going to work right
> with what we have today... So they added to the audit Kconfig:
>
> depends on AUDIT && (X86 || PPC || S390 || IA64 || UML || SPARC64 ||
> SUPERH || (ARM && AEABI && !OABI_COMPAT))
Hmm, so that might be your "out" here, unless you really want to deal with ARM
OABI :) I'm not even entirely sure if OABI works on the newer ARM hardware.
> Is fixing this with differentiated AUDIT_ARCH flags even possible? Am I
> just talking out of my bum?
/me shrugs
Sorry, still learning this stuff too.
--
paul moore
security and virtualization @ redhat
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-10-29 21:56 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-10-29 21:28 ABIs, syscall tables, and the AUDIT_ARCH_* defines Paul Moore
2013-10-29 21:29 ` Eric Paris
2013-10-29 21:56 ` Paul Moore
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.