offsets for 64bit IPC mechanisms

[Steve Grubb]

Hello,

BZ 221663 was opened to report a problem with some test results. From the 
bugzilla:

semctl(id, 0, IPC_RMID);
Expected argument: a0 = SEMCTL, a1 = id, a2 = 0, a3 = 0 (IPC_RMID)
Actual arguments seen in the audit log: a0 = SEMCTL, a1 = id, a2 = 0, a3 = 
0x100

msgctl(id, IPC_STAT, &buf)
Expected argument: a0 = MSGCTL, a1 = id, a2 = 2 (IPC_STAT)
Actual arguments seen in the audit log: a0 = MSGCTL, a1 = id, a2 = 0x102

The answer was:

/*
 * Version flags for semctl, msgctl, and shmctl commands
 * These are passed as bitflags or-ed with the actual command
 */
#define IPC_OLD 0       /* Old version (no 32-bit UID support on many
                           architectures) */
#define IPC_64  0x0100  /* New version (support 32-bit UIDs, bigger
                           message sizes, etc. */

Looks like userspace will "or" the value with IPC_64 to indicate the version 
it supports.


So the question is, should ausearch report the actual recorded register value, 
or should it "and" the register with IPC_64 ?

-Steve