public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: Eric Paris <eparis@redhat.com>
To: Manuel Lauss <manuel.lauss@gmail.com>
Cc: linux-audit@redhat.com, Linux-MIPS <linux-mips@linux-mips.org>
Subject: Re: [RESEND PATCH 1/2] MIPS syscall auditing patches
Date: Thu, 03 Apr 2014 10:04:13 -0400	[thread overview]
Message-ID: <1396533853.24733.33.camel@flatline.rdu.redhat.com> (raw)
In-Reply-To: <1396433596-612624-2-git-send-email-manuel.lauss@gmail.com>

On Wed, 2014-04-02 at 12:13 +0200, Manuel Lauss wrote:
> From: Ralf Baechle <ralf@linux-mips.org>
> 
> this is the first cut of the MIPS auditing patches.  MIPS doesn't quite
> fit into the existing pattern of other architectures and I'd appreciate
> your comments and maybe even an Acked-by.
> 
>  - MIPS syscalls return a success / error flag in register $7.  If the
>    flag is set then the return value in $2 is a *positive* error value.
>    This means the existing AUDITSC_RESULT() macro does not work on
>    MIPS and thus ptrace.c defines it's own version MIPS_AUDITSC_RESULT().

This is not needed (and not used by your patch).  The kernel uses a
combination of is_syscall_success(), regs_return_value(), and
syscall_get_arch().  The first 2 look good, the third looks like it
needs to be reworked a little....

>  - Linux on MIPS extends the traditional syscall table used by older UNIX
>    implementations.  This is why 32-bit Linux syscalls are starting from
>    4000; the native 64-bit syscalls start from 5000 and the N32 compat ABI
>    from 6000.  The existing syscall bitmap is only large enough for at most
>    2048 syscalls, so I had to increase AUDIT_BITMASK_SIZE to 256 which
>    provides enough space for 8192 syscalls.  Because include/linux/audit.h
>    and AUDIT_BITMASK_SIZE are exported to userspace I've used an #ifdef
>    __mips__ for this.

Seems like we have little/no other choice.

>  - I've introduced a flag __AUDIT_ARCH_ALT to indicate an alternative ABI.
>    The name of the flag is intentionally very generic to make the name
>    hopefully fit other architectures' eventual need as well.  On MIPS it
>    indicates the 3rd ABI known as N32.

Sounds about as good as we can do.

>  - To make matters worse, most MIPS processors can be configured to be
>    big or little endian.  Traditionally the the 64-bit little endian
>    configuration is named mips64el, so I've changed references to MIPSEL64
>    in audit.h to MIPS64EL.

Feel free to change it.  We can put the old name back if someone was
potentially using it...

>  - The code treats the little endian MIPS architecture as separate from
>    big endian.  Combined with the 3 ABIs that's 6 combinations.  I tried
>    to sort of follow the example set by ARM which explicitly lists the
>    (rare) big endian architecture variant - but it doesn't seem to very
>    useful so I wonder if this could be squashed to just the three ABIs
>    without consideration of endianess?

Yes, squash.  Assuming the syscall table is the exact same, we don't
actually care.  We send info to userspace in string order, not
endianness order, so it doesn't matter...

>  - Talking about flags; I've defined the the N32 architecture flags were defined
> 
>     #define AUDIT_ARCH_MIPS64_N32  (EM_MIPS|__AUDIT_ARCH_ALT)
>     #define AUDIT_ARCH_MIPS64EL_N32 (EM_MIPS|__AUDIT_ARCH_ALT|__AUDIT_ARCH_LE
> 
>     N32 is a 32-bit ABI but one that only runs on 64-bit processors as it
>     uses 64-bit registers for 64-bit integers.  So I'm uncertain if the
>     __AUDIT_ARCH_64BIT flags should be set or not.

As long as AUDIT_ARCH_MIPS64EL_N32 is uniquely identifiable you are
fine.  I'm assuming the syscall arguments are 64bit long.  So lets just
call it a 64BIT arch...

  parent reply	other threads:[~2014-04-03 14:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-02 10:13 [RESEND PATCH 0/2] MIPS syscall auditing patches Manuel Lauss
2014-04-02 10:13 ` [RESEND PATCH 1/2] " Manuel Lauss
2014-04-02 15:56   ` Richard Guy Briggs
2014-04-03  9:32     ` Ralf Baechle
2014-04-03 13:12       ` Steve Grubb
2014-04-03 13:48       ` David Woodhouse
2014-04-03 13:58         ` Eric Paris
2014-04-03 14:36           ` David Woodhouse
2014-04-03 15:13         ` Richard Guy Briggs
2014-04-03 14:04   ` Eric Paris [this message]
2014-04-02 10:13 ` [RESEND PATCH 2/2] " Manuel Lauss

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1396533853.24733.33.camel@flatline.rdu.redhat.com \
    --to=eparis@redhat.com \
    --cc=linux-audit@redhat.com \
    --cc=linux-mips@linux-mips.org \
    --cc=manuel.lauss@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox