On Wed, May 02, 2012 at 03:48:10PM +0100, Eric Paris wrote:

On Wed, 2012-05-02 at 10:10 -0400, Jon Masters wrote:

quoted

On May 2, 2012, at 4:58 AM, Will Deacon wrote:

quoted

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:

Absolutely I will get all references s/ARMEB/ARM/g in the userspace
tools.

Cracking, thanks.

Endianness doesn't really matter from audit's PoV.  It really cares
about ABI.  Most of the communication from kernel to userspace is
strings.  The only portion of that communiction which doesn't seem to be
a string is the netlink message type.  So as long as userspace is the
same endianness as the kernel creating the netlink message the type is
going to come out just fine.  Historically ABI has been indicated by a
mixture of 32/64bit, endianness, and the elf header e_machine field.

For ARM, we can't really use the endianness to tell us anything about the
ABI. You'll need to rely on the ELF header instead (see EF_ARM_EABI_MASK).
With that, can we get rid of the endianness checks in ptrace.c and simply
advertise AUDIT_ARCH_ARM unconditionally?

quoted

quoted

(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.

Well, we care enough about it not to cause regressions since some people are
still using it. I would say that audit can be EABI only though (we can add
support later for OABI if somebody shouts).

I'm fine with not supporting things.  But I'm pretty stupid here.  Is
this just not supporting some old chip?  Or is this some ABI that a new
chip could have both and can switch at run time?  If the latter, we need
to support it.  If the former, and hints on how to make sure you can't
build audit with OABI?

My current hack in the kernel is to change the Kconfig entries for audit. As
for userspace, I guess you have to check the toolchain triplet somehow. v6
onwards makes use only of EABI and it's becoming increasingly more difficult
to find distributions supporting OABI (required for CPUs prior to v4t).

Short answer: audit can concern itself only with EABI.

quoted

quoted

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'.

Got a patch?

Something like:

Index: lib/libaudit.c
===================================================================

--- lib/libaudit.c	(revision 693)
+++ lib/libaudit.c	(working copy)

@@ -1327,6 +1327,10 @@
 						if (bits == __AUDIT_ARCH_64BIT)
 							return -6;
 						break;
+					case MACH_ARMEB:
+						if (bits == __AUDIT_ARCH_64BIT)
+							return -6;
+						break;
 					case MACH_86_64: /* fallthrough */
 					case MACH_PPC64: /* fallthrough */
 					case MACH_S390X: /* fallthrough */

Will