Re: [RESEND PATCH 1/2] MIPS syscall auditing patches
On 14/04/03, David Woodhouse wrote: > On Thu, 2014-04-03 at 11:32 +0200, Ralf Baechle wrote: > The __AUDIT_ARCH_64BIT flag does allow you to distinguish between 32-bit > and 64-bit system calls on architectures where you can't tell them apart > by syscall number alone (e.g. S390?). But even that isn't really needed > on MIPS because the syscall number tells you *everything* you need to > know, doesn't it? That hadn't even occured to me. So, why not use O32, N32 and 64 flags and just take mod 1000 of the syscall number and use a 64-bit mask? Or drop the 3 arch flags and just identify the arch from the syscall number range alone? > David WoodhouseOpen Source Technology Centre - RGB -- Richard Guy Briggs Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: [RESEND PATCH 1/2] MIPS syscall auditing patches
On Thu, 2014-04-03 at 09:58 -0400, Eric Paris wrote: > Same for the 64BIT flag. Do what makes sense to identify the arch and > don't worry to much about it. (sounds to me like MIPS has 3 arches) Since the syscall numbers are disjoint for the three MIPS "arches", you could surely consider it to be just one? I've kind of missed the point of why that's an improvement though. There was something about the size of the syscall table, and having 3 (or 6) copies of it...? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: [RESEND PATCH 1/2] MIPS syscall auditing patches
On Wed, 2014-04-02 at 12:13 +0200, Manuel Lauss wrote: > From: Ralf Baechle > > 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... -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: [RESEND PATCH 1/2] MIPS syscall auditing patches
On Thu, 2014-04-03 at 14:48 +0100, David Woodhouse wrote: > On Thu, 2014-04-03 at 11:32 +0200, Ralf Baechle wrote: > > > > There's probably the odd bitfield or similar where it might matter? I > > did dig a bit in the history of the auditing code and found no code > > that uses __AUDIT_ARCH_LE other than setting that flag. > > > > David - you introduced __AUDIT_ARCH_LE in kernel commit 2fd6f58ba6e > > "[AUDIT] Don't allow ptrace to fool auditing, log arch of audited > > syscalls." on April 29 2005. Do you still recall the purpose of this > > flag? > > Obviously I remember nothing. But I really can't see the point in the > little-endian flag. Perhaps it just seemed like a good idea at the time. > > The __AUDIT_ARCH_64BIT flag does allow you to distinguish between 32-bit > and 64-bit system calls on architectures where you can't tell them apart > by syscall number alone (e.g. S390?). But even that isn't really needed > on MIPS because the syscall number tells you *everything* you need to > know, doesn't it? > > Even if we started supporting little-endian system calls on a big-endian > kernel, __AUDIT_ARCH_LE would help with interpreting the output, since > it's never in a bytewise/binary form *anyway*. It would let you filter > on LE vs. BE system calls I suppose, but I'm not sure if that's a > required feature. The only point of these flags is to uniquely identify the arch. If the arch has LE and BE, but it doesn't change the API in any way, it doesn't matter. Don't worry about it. Same for the 64BIT flag. Do what makes sense to identify the arch and don't worry to much about it. (sounds to me like MIPS has 3 arches) -Eric -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: [RESEND PATCH 1/2] MIPS syscall auditing patches
On Thu, 2014-04-03 at 11:32 +0200, Ralf Baechle wrote: > > There's probably the odd bitfield or similar where it might matter? I > did dig a bit in the history of the auditing code and found no code > that uses __AUDIT_ARCH_LE other than setting that flag. > > David - you introduced __AUDIT_ARCH_LE in kernel commit 2fd6f58ba6e > "[AUDIT] Don't allow ptrace to fool auditing, log arch of audited > syscalls." on April 29 2005. Do you still recall the purpose of this > flag? Obviously I remember nothing. But I really can't see the point in the little-endian flag. Perhaps it just seemed like a good idea at the time. The __AUDIT_ARCH_64BIT flag does allow you to distinguish between 32-bit and 64-bit system calls on architectures where you can't tell them apart by syscall number alone (e.g. S390?). But even that isn't really needed on MIPS because the syscall number tells you *everything* you need to know, doesn't it? Even if we started supporting little-endian system calls on a big-endian kernel, __AUDIT_ARCH_LE would help with interpreting the output, since it's never in a bytewise/binary form *anyway*. It would let you filter on LE vs. BE system calls I suppose, but I'm not sure if that's a required feature. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: [RESEND PATCH 1/2] MIPS syscall auditing patches
On Thursday, April 03, 2014 11:32:57 AM Ralf Baechle wrote: > > > - 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. > > > > > > - 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? > > > > In ARM's case, endian-ness doesn't affect the ABI, from what I > > understand. > > There's probably the odd bitfield or similar where it might matter? I > did dig a bit in the history of the auditing code and found no code that > uses __AUDIT_ARCH_LE other than setting that flag. > > David - you introduced __AUDIT_ARCH_LE in kernel commit 2fd6f58ba6e > "[AUDIT] Don't allow ptrace to fool auditing, log arch of audited syscalls." > on April 29 2005. Do you still recall the purpose of this flag? I am certain its to signify the syscall is Little Endian. > > > - 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. > > > > I would guess it should, but I am no expert. > > Steve? The core issue is to tell the kernel exactly what syscall you want inspected by the audit system. You should be able to specify a particular ABI and syscall and get that and only that. Then the event should record the information so that user space can figure out which syscall table to lookup the syscall number from so that it can turn it into text. Using the LE and other flags helps to know what we are dealing with if you have events aggregated in a server from multiple machines of different CPUs. Assuming the AUDIT_ARCH_* follows expected conventions, the main test for correctness is whether or not you get a round trip from rules to interpreted events, its exactly what was expected. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: [RESEND PATCH 1/2] MIPS syscall auditing patches
On Wed, Apr 02, 2014 at 11:56:23AM -0400, Richard Guy Briggs wrote: (Adding dwmw2 who might give some insight on the purpose of __AUDIT_ARCH_LE to cc.) > > 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(). > > > > - 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. > > Is this really necessary? I don't have any background on the choice of > syscall numbers on MIPS. > > Instead of 4000, 5000, and 6000, could it not have used 500, 1000, 1500 > as base numbers given that there are 350 syscalls? And when those numbers were chosen Linux had half as many syscalls! The choice is due to RISC/os which used the same values for it's 4 ABIs. Linux reserved those 4 × 1000 syscall slots to allow a compatibility mode to be implemented (which never happened) and extended the scheme with native 32 bit calls starting at 4000 and a few years later native 64 bit calls at 5000 and N32 calls at 6000. If it was me I'd have offset the syscalls by 1024 which would have sped up and simplified a few things. Or totally different - but for a long time risc/OS rsp. IRIX were the de facto standards being followed for such kernel interface details. > > - 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. > > Is N32 sufficiently different from the concept of "compat" that that > could not be used? Does the behaviour of 64-bit integers prevent this? N32 is a 32 bit ABI - but one that requires a 64 bit processor as it uses 64 bit integer registers. So in that aspect it's a 64 bit ABI. However N32's address space is still 32 bit only that is for exapmle all structures that contain addresses are using the 32 bit definition; also its pointeger and long integers are 32 bit. That also means that not even all the syscalls are identical to either O32 or N64. > > - 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. > > > > - 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? > > In ARM's case, endian-ness doesn't affect the ABI, from what I > understand. There's probably the odd bitfield or similar where it might matter? I did dig a bit in the history of the auditing code and found no code that uses __AUDIT_ARCH_LE other than setting that flag. David - you introduced __AUDIT_ARCH_LE in kernel commit 2fd6f58ba6e "[AUDIT] Don't allow ptrace to fool auditing, log arch of audited syscalls." on April 29 2005. Do you still recall the purpose of this flag? > > - 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. > > I would guess it should, but I am no expert. Steve? Ralf -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: [RESEND PATCH 1/2] MIPS syscall auditing patches
On 14/04/02, Manuel Lauss wrote: > From: Ralf Baechle > > 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(). > > - 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. Is this really necessary? I don't have any background on the choice of syscall numbers on MIPS. Instead of 4000, 5000, and 6000, could it not have used 500, 1000, 1500 as base numbers given that there are 350 syscalls? > - 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. Is N32 sufficiently different from the concept of "compat" that that could not be used? Does the behaviour of 64-bit integers prevent this? > - 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. > > - 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? In ARM's case, endian-ness doesn't affect the ABI, from what I understand. > - 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. I would guess it should, but I am no expert. > Thanks in advance, > > Signed-off-by: Ralf Baechle > --- > mlau: this is the patch Ralf sent in June 2011, I've just rediffed it against > latest linux (3.15-rc0). > > arch/mips/Kconfig | 12 + > arch/mips/include/asm/abi.h | 1 + > arch/mips/include/uapi/asm/unistd.h | 18 +--- > arch/mips/kernel/Makefile | 4 ++ > arch/mips/kernel/audit-n32.c| 58 +++ > arch/mips/kernel/audit-native.c | 92 > + > arch/mips/kernel/audit-o32.c| 60 > arch/mips/kernel/ptrace.c | 7 +++ > arch/mips/kernel/signal.c | 20 +++- > arch/mips/kernel/signal32.c | 10 +++- > arch/mips/kernel/signal_n32.c | 10 +++- > include/uapi/linux/audit.h | 21 - > init/Kconfig| 3 +- > 13 files changed, 305 insertions(+), 11 deletions(-) > create mode 100644 arch/mips/kernel/audit-n32.c > create mode 100644 arch/mips/kernel/audit-native.c > create mode 100644 arch/mips/kernel/audit-o32.c > > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig > index ecccd15..f1435b1 100644 > --- a/arch/mips/Kconfig > +++ b/arch/mips/Kconfig > @@ -49,6 +49,7 @@ config MIPS > select CLONE_BACKWARDS > select HAVE_DEBUG_STACKOVERFLOW > select HAVE_CC_STACKPROTECTOR > + select AUDIT_ARCH > > menu "Machine selection" > > @@ -846,6 +847,15 @@ config FW_ARC > config ARCH_MAY_HAVE_PC_FDC > bool > > +config AUDIT_ARCH > + bool > + > +config AUDITSYSCALL_O32 > + bool > + > +config AUDITSYSCALL_N32 > + bool > + > config BOOT_RAW > bool > > @@ -2516,6 +2526,7 @@ config SYSVIPC_COMPAT > config MIPS32_O32 > bool "Kernel support for o32 binaries" > depends on MIPS32_COMPAT > + select AUDITSYSCALL_O32 if AUDITSYSCALL > help > Select this option if you want to run o32 binaries. These are pure > 32-bit binaries as used by the 32-bit Linux/MI
[RESEND PATCH 1/2] MIPS syscall auditing patches
From: Ralf Baechle
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().
- 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.
- 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.
- 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.
- 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?
- 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.
Thanks in advance,
Signed-off-by: Ralf Baechle
---
mlau: this is the patch Ralf sent in June 2011, I've just rediffed it against
latest linux (3.15-rc0).
arch/mips/Kconfig | 12 +
arch/mips/include/asm/abi.h | 1 +
arch/mips/include/uapi/asm/unistd.h | 18 +---
arch/mips/kernel/Makefile | 4 ++
arch/mips/kernel/audit-n32.c| 58 +++
arch/mips/kernel/audit-native.c | 92 +
arch/mips/kernel/audit-o32.c| 60
arch/mips/kernel/ptrace.c | 7 +++
arch/mips/kernel/signal.c | 20 +++-
arch/mips/kernel/signal32.c | 10 +++-
arch/mips/kernel/signal_n32.c | 10 +++-
include/uapi/linux/audit.h | 21 -
init/Kconfig| 3 +-
13 files changed, 305 insertions(+), 11 deletions(-)
create mode 100644 arch/mips/kernel/audit-n32.c
create mode 100644 arch/mips/kernel/audit-native.c
create mode 100644 arch/mips/kernel/audit-o32.c
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index ecccd15..f1435b1 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -49,6 +49,7 @@ config MIPS
select CLONE_BACKWARDS
select HAVE_DEBUG_STACKOVERFLOW
select HAVE_CC_STACKPROTECTOR
+ select AUDIT_ARCH
menu "Machine selection"
@@ -846,6 +847,15 @@ config FW_ARC
config ARCH_MAY_HAVE_PC_FDC
bool
+config AUDIT_ARCH
+ bool
+
+config AUDITSYSCALL_O32
+ bool
+
+config AUDITSYSCALL_N32
+ bool
+
config BOOT_RAW
bool
@@ -2516,6 +2526,7 @@ config SYSVIPC_COMPAT
config MIPS32_O32
bool "Kernel support for o32 binaries"
depends on MIPS32_COMPAT
+ select AUDITSYSCALL_O32 if AUDITSYSCALL
help
Select this option if you want to run o32 binaries. These are pure
32-bit binaries as used by the 32-bit Linux/MIPS port. Most of
@@ -2526,6 +2537,7 @@ config MIPS32_O32
config MIPS32_N32
bool "Kernel support for n32 binaries"
depends on MIPS32_COMPAT
+ select AUDITSYSCALL_N32 if AUDITSYSCALL
help
Select this option if you want to run n32 binaries. These are
64-bit binaries using 32-bit quantities for addressing and certain
diff --git a/arch/mips/include/asm/abi.h b/arch/mips/include/asm/abi.h
index 909bb69..7ae5eed 100644
--- a/arch/mips/include/asm/abi.h
+++ b/arch/mips/include/asm/abi.h
@@ -22,6 +22,7 @@ struct mips_abi {
sigset_t *set, siginfo_t *info);
const unsigned long rt_signal_return_offset;
