[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