x32 + audit status?

x32 + audit status?

[David Drysdale]

Hi,

Do we currently expect the audit system to work with x32 syscalls?

I was playing with the audit system for the first time today (on
v4.0-rc2, due to [1]), and it didn't seem to work for me.  (Tweaking
ptrace.c like the patch below seemed to help, but I may just have
configured something wrong.)

I know there was a bunch of activity around this area in mid-2014,
but I'm not sure what the final position was...

Thanks,
David

[1]: https://lkml.org/lkml/2015/3/4/879

diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index e510618b2e91..443932afd9e8 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -1445,7 +1445,7 @@ static void do_audit_syscall_entry(struct
pt_regs *regs, u32 arch)
 {
 #ifdef CONFIG_X86_64
        if (arch == AUDIT_ARCH_X86_64) {
-               audit_syscall_entry(regs->orig_ax, regs->di,
+               audit_syscall_entry(regs->orig_ax & __SYSCALL_MASK, regs->di,
                                    regs->si, regs->dx, regs->r10);
        } else
 #endif

Re: x32 + audit status?

[Andy Lutomirski]

On Mar 5, 2015 10:32 AM, "David Drysdale" <drysdale@google.com> wrote:
>
> Hi,
>
> Do we currently expect the audit system to work with x32 syscalls?
>
> I was playing with the audit system for the first time today (on
> v4.0-rc2, due to [1]), and it didn't seem to work for me.  (Tweaking
> ptrace.c like the patch below seemed to help, but I may just have
> configured something wrong.)
>
> I know there was a bunch of activity around this area in mid-2014,
> but I'm not sure what the final position was...

It's totally broken, and it needs ABI work.  I think it should keep
the high syscall numbers, which means that both userspace and the
audit core need to learn how to deal with it.

--Andy

>
> Thanks,
> David
>
> [1]: https://lkml.org/lkml/2015/3/4/879
>
> diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
> index e510618b2e91..443932afd9e8 100644
> --- a/arch/x86/kernel/ptrace.c
> +++ b/arch/x86/kernel/ptrace.c
> @@ -1445,7 +1445,7 @@ static void do_audit_syscall_entry(struct
> pt_regs *regs, u32 arch)
>  {
>  #ifdef CONFIG_X86_64
>         if (arch == AUDIT_ARCH_X86_64) {
> -               audit_syscall_entry(regs->orig_ax, regs->di,
> +               audit_syscall_entry(regs->orig_ax & __SYSCALL_MASK, regs->di,
>                                     regs->si, regs->dx, regs->r10);
>         } else
>  #endif

Re: x32 + audit status?

[Paul Moore]

On Thu, Mar 5, 2015 at 6:07 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Mar 5, 2015 10:32 AM, "David Drysdale" <drysdale@google.com> wrote:
>>
>> Hi,
>>
>> Do we currently expect the audit system to work with x32 syscalls?
>>
>> I was playing with the audit system for the first time today (on
>> v4.0-rc2, due to [1]), and it didn't seem to work for me.  (Tweaking
>> ptrace.c like the patch below seemed to help, but I may just have
>> configured something wrong.)
>>
>> I know there was a bunch of activity around this area in mid-2014,
>> but I'm not sure what the final position was...
>
> It's totally broken, and it needs ABI work.  I think it should keep
> the high syscall numbers, which means that both userspace and the
> audit core need to learn how to deal with it.

What Andy said.  It's on the list of things to fix, but to be brutally
honest, it's not very high on the list due to lack of interest from
people asking for audit/x32 support.

Re: x32 + audit status?

[David Drysdale]

On Fri, Mar 6, 2015 at 7:28 AM, Paul Moore <paul@paul-moore.com> wrote:
> On Thu, Mar 5, 2015 at 6:07 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Mar 5, 2015 10:32 AM, "David Drysdale" <drysdale@google.com> wrote:
>>>
>>> Hi,
>>>
>>> Do we currently expect the audit system to work with x32 syscalls?
>>>
>>> I was playing with the audit system for the first time today (on
>>> v4.0-rc2, due to [1]), and it didn't seem to work for me.  (Tweaking
>>> ptrace.c like the patch below seemed to help, but I may just have
>>> configured something wrong.)
>>>
>>> I know there was a bunch of activity around this area in mid-2014,
>>> but I'm not sure what the final position was...
>>
>> It's totally broken, and it needs ABI work.  I think it should keep
>> the high syscall numbers, which means that both userspace and the
>> audit core need to learn how to deal with it.
>
> What Andy said.  It's on the list of things to fix, but to be brutally
> honest, it's not very high on the list due to lack of interest from
> people asking for audit/x32 support.

Fair enough -- thanks for letting me know.