Fw: audit syscall information.

In our syscalls, we are currently checking the expected values of some of the syscall parameters. We do not always check a0, a1, a2, and a3. One syscall may check a0, a1, and a2. Another may only check a0, and a1. When we compile our syscalls in 32bit mode on a 64bit system, the a0, a1, a2, a3 values are no longer what we expected them to be. For example, in our access syscall test a0 = pathname a1 = mode When we compile and run in 64bit mode: The audit record looks like: type=KERNEL msg=audit(1114696605.916:2151478): item=0 name=". /mytest.9825" inode=6062205 dev=fd:00 mode=0100004 uid=0 gid=0 rdev=00:00 type=KERNEL msg=audit(1114696605.916:2151478): syscall=21 arch=c000003e success=yes exit=0 a0=50a460 a1=4 a2=3cb762ea03 a3=0 items=1 pid=9825 loginuid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="access_test" exe=/deb/rhcc/eal4/tests/LTP/ltp-full/testcases/audit/filters/access_test From our test: access_test 0 INFO : expected (pfilename) a0 s=./mytest.9825 h=50a460 d=5284960 u=5284960. (expected a0 printed as a string, hex, decimal, unsigned values) Note audit record a0=50a460 which matches expected value printed in hex access_test 0 INFO : expected (access_mode) a1 h=4 d=4 u=4. (expected a1 printed as a hex, decimal, and unsigned value) Note audit record a1=4 which matches expected (printed in %x, %d, and

access_test 0 INFO : expected (pfilename) objectname

Matches "name" in audit record" access_test 1 PASS : Expected record found! When we compile and run in 32bit mode: type=KERNEL msg=audit(1114696996.822:2260436): item=0 name=". /mytest.10196" inode=6062205 dev=fd:00 mode=0100004 uid=0 gid=0

access_test 0 INFO : expected (pfilename) objectname

access_test 1 FAIL : Expected record not found. I know David put some hooks in for the ipc syscalls, I haven't been able to test those to see if that corrects this problem for those or not. I'm not sure when that fix was introduced. I'm currently running on kernel.2.6.9-5.0.3.EL.audit.20 and this problem is true for the ipc syscalls as well. If that does fix the problem, should our tests only check a0, a1, a2, a3 values for the syscalls which David is adding these hooks? Thanks, debbie