[PATCH Resend] MIPS: Add syscall auditing support

[Paul Moore]

On Mon, Apr 27, 2020 at 5:12 AM Huacai Chen <chenhuacai at gmail.com> wrote:
> On Thu, Mar 12, 2020 at 5:33 PM Huacai Chen <chenhc at lemote.com> wrote:
> >
> > From: Ralf Baechle <ralf at linux-mips.org>
> >
> > The original patch is from Ralf. I have maintained it for more than six
> > years on Loongson platform, and it works perfectly. Most of the commit
> > messages are written by Ralf.
> >
> > MIPS doesn't quite fit into the existing pattern of other architectures
> > and I'd appreciate your comments and maybe even an Acked-by.
> >
> >  - 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/uapi/linux/
> >    audit.h and AUDIT_BITMASK_SIZE are exported to userspace I've used an
> >    #ifdef __mips__ for this.

I'm sure you're aware of the hacky nature of such a change and
considering that it is a break in the kernel/userspace API, hacky
changes make me nervous.  Very nervous.

The ultimate fix for this would be to move away from passing structs
across netlink and use netlink attributes; this would allow us the
flexibility to tweak the fields like we would need for this without
completely breaking existing systems.  However, that is a big chunk of
work (and I'm just talking about the control plane, not the audit
records themselves as has been discussed in the past) and I can
understand if that is not something you want to take on at this point.

A less disruptive, but even more of an awful hack would be to extend
past the end of the audit_rule_data struct with an audit_rule_data_ext
(?) struct (perhaps indicated by a flag), but that is tricky due the
variable length buffer at the end of audit_rule_data.  I *really*
dislike this idea, but it is *an* idea.

I'm open to suggestions, but my current leaning is that if we are
going to add support for MIPS, we'll need to actually do the work to
convert the netlink control plane to use netlink attributes.

> >  - 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?

Forgive my ignorance of MIPS, but as I understand it there is 32-bit
MIPS (old-ABI), 64-bit MIPS (new-ABI), and 64/32-bit MIPS (new-API,
aka N32); with each having both little and big endian variants, is
that correct?

Is it also safe to assume that 64-bit MIPS (new-API) can only run
64-bit new-API and N32 binaries and *not* 32-bit old-API binaries?

I'm guessing MIPS does not support running both little and big endian
binaries simultaneously on the same booted system?  Or does it?

-- 
paul moore
www.paul-moore.com