[PATCH] ARM: Fix restoration of IP scratch register when auditing syscalls
Jon Masters
jonathan at jonmasters.org
Wed May 2 10:10:09 EDT 2012
On May 2, 2012, at 4:58 AM, Will Deacon wrote:
> On Wed, May 02, 2012 at 07:27:22AM +0100, Jon Masters wrote:
>> Right. So audit userspace has this:
>>
>> static const struct int_transtab elftab[] = {
>> { MACH_X86, AUDIT_ARCH_I386 },
>> { MACH_86_64, AUDIT_ARCH_X86_64 },
>> { MACH_IA64, AUDIT_ARCH_IA64 },
>> { MACH_PPC64, AUDIT_ARCH_PPC64 },
>> { MACH_PPC, AUDIT_ARCH_PPC },
>> { MACH_S390X, AUDIT_ARCH_S390X },
>> { MACH_S390, AUDIT_ARCH_S390 },
>> #ifdef WITH_ALPHA
>> { MACH_ALPHA, AUDIT_ARCH_ALPHA }
>> #endif
>> #ifdef WITH_ARMEB
>> { MACH_ARMEB, AUDIT_ARCH_ARMEB }
>> #endif
>> };
>
> Yes -- it seems that ARMEB was confused with ARM EABI, so it's probably
> worth dropping the -EB suffix in the tools and then updating the RHS of the
> above table to use the little-endian identifier. This raises some questions:
>
> (1) Why does endianness come into this? Is there some structure parsing code
> somewhere that I can't see or is there an assumption about syscall ABIs
> being necessarily different if the endianness changes?
Can Eric or someone else provide context here?
> (2) What do we do about OABI? I think the two choices are either (a) add
> some new AUDIT_ARCH_ARM* entries (although then you have the messy
> problem of determining the ABI of the current task during tracing) or
> (b) support EABI only for the time being.
I think the answer is…nobody cares about OABI :) Seriously though, for
"new" stuff, let's just look to the future I say. But that's my opinion.
> I had to hack a random switch statement in the tools too, otherwise I got a
> cryptic message about `requested bit level not supported by machine'.
>
> Anyway, I threw the kernel changes into my audit branch and will re-post later
> on.
Cool. And you'll make sure stable is CC'd on this specific patch too?
Jon.
More information about the linux-arm-kernel
mailing list