[RESEND PATCH 1/2] MIPS syscall auditing patches

[Eric Paris]

On Thu, 2014-04-03 at 14:48 +0100, David Woodhouse wrote:
> On Thu, 2014-04-03 at 11:32 +0200, Ralf Baechle wrote:
> > 
> > There's probably the odd bitfield or similar where it might matter?  I
> > did dig a bit in the history of the auditing code and found no code
> > that uses __AUDIT_ARCH_LE other than setting that flag.
> > 
> > David - you introduced __AUDIT_ARCH_LE in kernel commit 2fd6f58ba6e
> > "[AUDIT] Don't allow ptrace to fool auditing, log arch of audited
> > syscalls." on April 29 2005.  Do you still recall the purpose of this
> > flag?
> 
> Obviously I remember nothing. But I really can't see the point in the
> little-endian flag. Perhaps it just seemed like a good idea at the time.
> 
> The __AUDIT_ARCH_64BIT flag does allow you to distinguish between 32-bit
> and 64-bit system calls on architectures where you can't tell them apart
> by syscall number alone (e.g. S390?). But even that isn't really needed
> on MIPS because the syscall number tells you *everything* you need to
> know, doesn't it?
> 
> Even if we started supporting little-endian system calls on a big-endian
> kernel, __AUDIT_ARCH_LE would help with interpreting the output, since
> it's never in a bytewise/binary form *anyway*. It would let you filter
> on LE vs. BE system calls I suppose, but I'm not sure if that's a
> required feature.

The only point of these flags is to uniquely identify the arch.  If the
arch has LE and BE, but it doesn't change the API in any way, it doesn't
matter.  Don't worry about it.

Same for the 64BIT flag.  Do what makes sense to identify the arch and
don't worry to much about it.  (sounds to me like MIPS has 3 arches)

-Eric