linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* ARM audit, seccomp, etc are broken wrt OABI syscalls
@ 2013-11-05 22:36 Andy Lutomirski
  2013-11-06  0:14 ` Kees Cook
  2013-11-06 15:32 ` [libseccomp-discuss] " Eric Paris
  0 siblings, 2 replies; 16+ messages in thread
From: Andy Lutomirski @ 2013-11-05 22:36 UTC (permalink / raw)
  To: Kees Cook
  Cc: Paul Moore, Richard Weinberger, libseccomp-discuss, Will Drewry,
	linux-kernel, linux-arm-kernel, Russell King

[-- Attachment #1: Type: text/plain, Size: 2231 bytes --]

[cc: some ARM people]

After a bit of an adventure, I got QEMU working.  (Linux 3.12's smc91x
driver and qemu 1.6 don't get along.  It would be great if some
kernel.org page described a standard way to boot a modern Linux image
on a modern QEMU version, but I digress.)

The current state of affairs is unhealthy.  I wrote a program
(attached) that does 'svc $0x90002f' (silly GNU syntax for "Issue the
getgid syscall in OABI").  The registers I program are:

r0: 1
r1: 2
r2: 3
r3: 4
r4: 5
r5: 6

(i.e. the arguments are 1,2,3,4,5,6, although getgid ignores them)

r7: 1

(r7 is the EABI syscall register.  On a kernel without OABI support,
the immediate svc argument is ignored and syscall 1, i.e. _exit, will
be invoked).

Seccomp sees the registers as I set them (unsurprisingly) and it sees
nr == 0x2f.  It passes those values on to a SIGSYS handler, if one
exists.  This is, IMO, bad.  The OABI and EABI argument passing
conventions are *not* the same, and seccomp filters that check syscall
argument values may be spoofable by using OABI calls.

I suspect that audit, perf, ftrace, and maybe even ptrace are broken
as well for exactly the same reason.

I would argue that there are two reasonable fixes:

1. Set a different audit arch for OABI syscalls (e.g.
AUDIT_ARCH_ARMOABI).  That is, treat OABI syscall entries the same way
that x86_64 treats int 80.

2. Leave the 0x900000 bits set in the syscall nr.  That way OABI
syscalls would look like a different set of syscalls on the same
architecture.  That is, treat OABI syscall entries kind of like x86_64
treats x32 syscalls.  (There's probably no reason to accept 0x900000 +
N as an r7 value to cause 'svc 0' to invoke OABI syscall N, though.)

3. Unconditionally kill any process that makes an OABI syscall with
seccomp enabled (because there should be no such programs).  Eww.

Options 1 and 2 are both break ABI, but I doubt that anythink cares.
OABI is, AFAICT, mostly dead.  That being said, even if nothing
legitimate uses OABI, exploits against seccomp-using programs can
certainly use OABI, so I think that this needs to be fixed somehow.

Thoughts?  I think I prefer option 1.  I don't really want to make the
change because my ARM assembly skills are lacking.

[-- Attachment #2: seccomp_oabi.c --]
[-- Type: text/x-csrc, Size: 2375 bytes --]

#define _GNU_SOURCE
#include <stdio.h>
#include <unistd.h>
#include <linux/filter.h>
#include <sys/syscall.h>
#include <err.h>
#include <sys/prctl.h>
#include <stddef.h>
#include <sys/ucontext.h>

#ifndef __ARM_EABI__
#error Must be compiled for ARM EABI
#endif

struct seccomp_data {
	int nr;
	__u32 arch;
	__u64 instruction_pointer;
	__u64 args[6];
};

#ifndef PR_SET_NO_NEW_PRIVS
#define PR_SET_NO_NEW_PRIVS	38
#endif

#define SECCOMP_RET_KILL 0x00000000U
#define SECCOMP_RET_TRAP 0x00030000U
#define SECCOMP_RET_ERRNO 0x00050000U
#define SECCOMP_RET_TRACE 0x7ff00000U
#define SECCOMP_RET_ALLOW 0x7fff0000U

struct sifields_sigsys {
	void *_call_addr;
	int _syscall;
	unsigned int _arch;
};

#define SIGINFO_SIGSYS(si) ((struct sifields_sigsys *)&(si)->_sifields)

__attribute__((noinline,optimize("2"))) long call_getgid_oabi(void)
{
	// If OABI compatibility is disabled, this will call exit instead
	// (That's what r7==1 means.)
	register long ret asm("r0");
	asm volatile("mov r0, $1\n\tmov r1, $2\n\tmov r2, $3\n\t"
		     "mov r3, $4\n\tmov r4, $5\n\tmov r5, $6\n\t"
		     "mov r7, $1\n\tsvc $0x90002f\n\t" : : :
		     "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7", "memory");
	return ret;
}

void handler(int signum, siginfo_t *si, void *uc_void)
{
	const struct ucontext *uc = uc_void;
	const struct sifields_sigsys *ss = SIGINFO_SIGSYS(si);

	printf("SIGSYS\n\n");
	printf("nr: 0x%X (__NR_getgid = 0x%X, OABI nr = 0x90002F)\n",
	       ss->_syscall, __NR_getgid);

#define DO_REG(i) printf("r" #i ":  0x%08X\n", uc->uc_mcontext.arm_r##i);
	DO_REG(0);
	DO_REG(1);
	DO_REG(2);
	DO_REG(3);
	DO_REG(4);
	DO_REG(5);
	DO_REG(6);
	DO_REG(7);
}

int main()
{
	int rc;

	struct sock_filter filter[] = {
		BPF_STMT(BPF_LD+BPF_W+BPF_ABS,
			 (offsetof(struct seccomp_data, nr))),
		BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, __NR_getgid, 0, 1),
		BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_TRAP),
		BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_ALLOW),
	};

	struct sock_fprog prog = {
		.len = (unsigned short)(sizeof(filter)/sizeof(filter[0])),
		.filter = filter,
	};

	struct sigaction sa = {};
	sa.sa_sigaction = handler;
	sa.sa_flags = SA_SIGINFO;
	if (sigaction(SIGSYS, &sa, NULL) != 0)
		err(1, "sigaction");

	if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0))
		err(1, "PR_SET_NO_NEW_PRIVS");
	if (prctl(PR_SET_SECCOMP, 2, &prog))
		err(1, "PR_SET_SECCOMP");

	call_getgid_oabi();

	return 0;
}

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
  2013-11-05 22:36 ARM audit, seccomp, etc are broken wrt OABI syscalls Andy Lutomirski
@ 2013-11-06  0:14 ` Kees Cook
  2013-11-06  0:40   ` Russell King - ARM Linux
  2013-11-06 22:30   ` Matt Sealey
  2013-11-06 15:32 ` [libseccomp-discuss] " Eric Paris
  1 sibling, 2 replies; 16+ messages in thread
From: Kees Cook @ 2013-11-06  0:14 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Paul Moore, Richard Weinberger, libseccomp-discuss, Will Drewry,
	linux-kernel, linux-arm-kernel, Russell King

On Tue, Nov 5, 2013 at 2:36 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> [cc: some ARM people]
>
> After a bit of an adventure, I got QEMU working.  (Linux 3.12's smc91x
> driver and qemu 1.6 don't get along.  It would be great if some
> kernel.org page described a standard way to boot a modern Linux image
> on a modern QEMU version, but I digress.)

Yeah, I kept losing this battle too, and most recently switch to using
mmc emulation instead of the SCSI emulation (CONFIG_MMC=y, and qemu's
"sd" disk driver).

> The current state of affairs is unhealthy.  I wrote a program
> (attached) that does 'svc $0x90002f' (silly GNU syntax for "Issue the
> getgid syscall in OABI").  The registers I program are:
>
> r0: 1
> r1: 2
> r2: 3
> r3: 4
> r4: 5
> r5: 6
>
> (i.e. the arguments are 1,2,3,4,5,6, although getgid ignores them)
>
> r7: 1
>
> (r7 is the EABI syscall register.  On a kernel without OABI support,
> the immediate svc argument is ignored and syscall 1, i.e. _exit, will
> be invoked).

Just to clarify: without CONFIG_OABI_COMPAT, all OABI syscalls turn into _exit?

> Seccomp sees the registers as I set them (unsurprisingly) and it sees
> nr == 0x2f.  It passes those values on to a SIGSYS handler, if one
> exists.  This is, IMO, bad.  The OABI and EABI argument passing
> conventions are *not* the same, and seccomp filters that check syscall
> argument values may be spoofable by using OABI calls.
>
> I suspect that audit, perf, ftrace, and maybe even ptrace are broken
> as well for exactly the same reason.
>
> I would argue that there are two reasonable fixes:
>
> 1. Set a different audit arch for OABI syscalls (e.g.
> AUDIT_ARCH_ARMOABI).  That is, treat OABI syscall entries the same way
> that x86_64 treats int 80.
>
> 2. Leave the 0x900000 bits set in the syscall nr.  That way OABI
> syscalls would look like a different set of syscalls on the same
> architecture.  That is, treat OABI syscall entries kind of like x86_64
> treats x32 syscalls.  (There's probably no reason to accept 0x900000 +
> N as an r7 value to cause 'svc 0' to invoke OABI syscall N, though.)
>
> 3. Unconditionally kill any process that makes an OABI syscall with
> seccomp enabled (because there should be no such programs).  Eww.
>
> Options 1 and 2 are both break ABI, but I doubt that anythink cares.
> OABI is, AFAICT, mostly dead.  That being said, even if nothing
> legitimate uses OABI, exploits against seccomp-using programs can
> certainly use OABI, so I think that this needs to be fixed somehow.
>
> Thoughts?  I think I prefer option 1.  I don't really want to make the
> change because my ARM assembly skills are lacking.

I would agree: option 1 seems cleanest of the 3. 3 is sort of like a
built-in automatic check for a mismatched arch, so maybe that works
better?

Alternatively, CONFIG_SECCOMP_FILTER could depend on
!CONFIG_OABI_COMPAT. That seems like the least work, given the desire
to kill OABI in the real world. (Though I would note that at least
Ubuntu's ARM kernels build with CONFIG_OABI_COMPAT; Chrome OS does
not.)

-Kees

-- 
Kees Cook
Chrome OS Security

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
  2013-11-06  0:14 ` Kees Cook
@ 2013-11-06  0:40   ` Russell King - ARM Linux
  2013-11-06  3:22     ` Andy Lutomirski
  2013-11-06  9:52     ` Mikael Pettersson
  2013-11-06 22:30   ` Matt Sealey
  1 sibling, 2 replies; 16+ messages in thread
From: Russell King - ARM Linux @ 2013-11-06  0:40 UTC (permalink / raw)
  To: Kees Cook
  Cc: Andy Lutomirski, Paul Moore, Richard Weinberger,
	libseccomp-discuss, Will Drewry, linux-kernel, linux-arm-kernel

On Tue, Nov 05, 2013 at 04:14:49PM -0800, Kees Cook wrote:
> I would agree: option 1 seems cleanest of the 3. 3 is sort of like a
> built-in automatic check for a mismatched arch, so maybe that works
> better?
> 
> Alternatively, CONFIG_SECCOMP_FILTER could depend on
> !CONFIG_OABI_COMPAT. That seems like the least work, given the desire
> to kill OABI in the real world. (Though I would note that at least
> Ubuntu's ARM kernels build with CONFIG_OABI_COMPAT; Chrome OS does
> not.)

OABI compat is really only something you want to deal with if you have
a reason to run OABI programs on the kernel; it is in no way guaranteed
that the OABI programs will run properly (many ALSA programs will not
because of different layouts with ioctls).

OABI compat was meant to allow a transition from OABI to EABI.  While
a lot of effort went in to the kernel side of that, which does allow
OABI based userspace to boot with an EABI kernel, and allows OABI built
test programs to run under an EABI kernel, actually being able to
migrate userland is far from trivial - and something that I've never
been able to do.  Hence, virtually all my long-running ARM machines
here are stuck with OABI, and I don't see that situation ever changing.

As a rule, distros should not be enabling OABI compat.  OABI compat
is more something that a developer (like me) who has a reason to enable
it turns it on.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
  2013-11-06  0:40   ` Russell King - ARM Linux
@ 2013-11-06  3:22     ` Andy Lutomirski
  2013-11-07 12:55       ` Henrique de Moraes Holschuh
  2013-11-06  9:52     ` Mikael Pettersson
  1 sibling, 1 reply; 16+ messages in thread
From: Andy Lutomirski @ 2013-11-06  3:22 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Kees Cook, Paul Moore, Richard Weinberger, libseccomp-discuss,
	Will Drewry, linux-kernel, linux-arm-kernel

On Tue, Nov 5, 2013 at 4:40 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Nov 05, 2013 at 04:14:49PM -0800, Kees Cook wrote:
>> I would agree: option 1 seems cleanest of the 3. 3 is sort of like a
>> built-in automatic check for a mismatched arch, so maybe that works
>> better?
>>
>> Alternatively, CONFIG_SECCOMP_FILTER could depend on
>> !CONFIG_OABI_COMPAT. That seems like the least work, given the desire
>> to kill OABI in the real world. (Though I would note that at least
>> Ubuntu's ARM kernels build with CONFIG_OABI_COMPAT; Chrome OS does
>> not.)
>
> OABI compat is really only something you want to deal with if you have
> a reason to run OABI programs on the kernel; it is in no way guaranteed
> that the OABI programs will run properly (many ALSA programs will not
> because of different layouts with ioctls).
>
> OABI compat was meant to allow a transition from OABI to EABI.  While
> a lot of effort went in to the kernel side of that, which does allow
> OABI based userspace to boot with an EABI kernel, and allows OABI built
> test programs to run under an EABI kernel, actually being able to
> migrate userland is far from trivial - and something that I've never
> been able to do.  Hence, virtually all my long-running ARM machines
> here are stuck with OABI, and I don't see that situation ever changing.
>
> As a rule, distros should not be enabling OABI compat.  OABI compat
> is more something that a developer (like me) who has a reason to enable
> it turns it on.

So I guess that audit, ptrace, etc. work on OABI because the userspace
tools expect the OABI syscall conventions and they work on EABI for
the same reason, everything is subtly broken on OABI compat.  Adding a
new AUDIT_ARCH_ARMOABI is probably bad, then, unless it only applies
to OABI compat kernels.  Similarly, bumping the syscall numbers is
probably also bad.  (Arguably the audit arch should have been
AUDIT_ARCH_ARMEABI from the beginning -- too late now.)

Maybe the thing to do is to put a warning in the config text for
CONFIG_OABI_COMPAT that describes the problems (malicious userspace
can confuse syscall auditors, strace, etc.), change the "if in doubt"
part to N, and disable seccomp filters if CONFIG_OABI_COMPAT.  That
might even get Debian to change their default.

--Andy

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
  2013-11-06  0:40   ` Russell King - ARM Linux
  2013-11-06  3:22     ` Andy Lutomirski
@ 2013-11-06  9:52     ` Mikael Pettersson
  1 sibling, 0 replies; 16+ messages in thread
From: Mikael Pettersson @ 2013-11-06  9:52 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Kees Cook, Will Drewry, Paul Moore, Richard Weinberger,
	linux-kernel, Andy Lutomirski, libseccomp-discuss,
	linux-arm-kernel

Russell King - ARM Linux writes:
 > OABI compat was meant to allow a transition from OABI to EABI.  While
 > a lot of effort went in to the kernel side of that, which does allow
 > OABI based userspace to boot with an EABI kernel, and allows OABI built
 > test programs to run under an EABI kernel, actually being able to
 > migrate userland is far from trivial - and something that I've never
 > been able to do.  Hence, virtually all my long-running ARM machines
 > here are stuck with OABI, and I don't see that situation ever changing.

I did a live incremental upgrade from OABI to EABI on my systems years
ago.  What I did was to first patch my OABI glibc to look for .so files
in oabi/ subdirectories.  Then I moved all OABI .so files to oabi/
subdirectories, and deleted all OABI static .a libraries.  After that
it was "simply" a matter of rebuilding everything as EABI, in the right
order.  The main advantage over this compared to a bootstrap-from-scratch
(which I've done 4 times on different architectures) was that I had access
to fully functional utilities and build tools from the start.

I _might_ be able to locate the glibc patch I used; do you want it?

/Mikael

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls
  2013-11-05 22:36 ARM audit, seccomp, etc are broken wrt OABI syscalls Andy Lutomirski
  2013-11-06  0:14 ` Kees Cook
@ 2013-11-06 15:32 ` Eric Paris
  2013-11-06 15:51   ` Russell King - ARM Linux
  1 sibling, 1 reply; 16+ messages in thread
From: Eric Paris @ 2013-11-06 15:32 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Kees Cook, Will Drewry, Richard Weinberger, linux-kernel,
	libseccomp-discuss, Russell King, linux-arm-kernel

On Tue, 2013-11-05 at 14:36 -0800, Andy Lutomirski wrote:
> [cc: some ARM people]
> 
> After a bit of an adventure, I got QEMU working.  (Linux 3.12's smc91x
> driver and qemu 1.6 don't get along.  It would be great if some
> kernel.org page described a standard way to boot a modern Linux image
> on a modern QEMU version, but I digress.)
> 
> The current state of affairs is unhealthy.  I wrote a program
> (attached) that does 'svc $0x90002f' (silly GNU syntax for "Issue the
> getgid syscall in OABI").  The registers I program are:
> 
> r0: 1
> r1: 2
> r2: 3
> r3: 4
> r4: 5
> r5: 6
> 
> (i.e. the arguments are 1,2,3,4,5,6, although getgid ignores them)
> 
> r7: 1
> 
> (r7 is the EABI syscall register.  On a kernel without OABI support,
> the immediate svc argument is ignored and syscall 1, i.e. _exit, will
> be invoked).
> 
> Seccomp sees the registers as I set them (unsurprisingly) and it sees
> nr == 0x2f.  It passes those values on to a SIGSYS handler, if one
> exists.  This is, IMO, bad.  The OABI and EABI argument passing
> conventions are *not* the same, and seccomp filters that check syscall
> argument values may be spoofable by using OABI calls.
> 
> I suspect that audit, perf, ftrace, and maybe even ptrace are broken
> as well for exactly the same reason.
> 
> I would argue that there are two reasonable fixes:
> 
> 1. Set a different audit arch for OABI syscalls (e.g.
> AUDIT_ARCH_ARMOABI).  That is, treat OABI syscall entries the same way
> that x86_64 treats int 80.

As the audit maintainer, I like #1.  It might break ABI, but the ABI is
flat wrong now and not maintainable...

> 
> 2. Leave the 0x900000 bits set in the syscall nr.  That way OABI
> syscalls would look like a different set of syscalls on the same
> architecture.  That is, treat OABI syscall entries kind of like x86_64
> treats x32 syscalls.  (There's probably no reason to accept 0x900000 +
> N as an r7 value to cause 'svc 0' to invoke OABI syscall N, though.)
> 
> 3. Unconditionally kill any process that makes an OABI syscall with
> seccomp enabled (because there should be no such programs).  Eww.
> 
> Options 1 and 2 are both break ABI, but I doubt that anythink cares.
> OABI is, AFAICT, mostly dead.  That being said, even if nothing
> legitimate uses OABI, exploits against seccomp-using programs can
> certainly use OABI, so I think that this needs to be fixed somehow.
> 
> Thoughts?  I think I prefer option 1.  I don't really want to make the
> change because my ARM assembly skills are lacking.
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most 
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> libseccomp-discuss mailing list
> libseccomp-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libseccomp-discuss



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls
  2013-11-06 15:32 ` [libseccomp-discuss] " Eric Paris
@ 2013-11-06 15:51   ` Russell King - ARM Linux
  2013-11-06 21:20     ` Will Drewry
  0 siblings, 1 reply; 16+ messages in thread
From: Russell King - ARM Linux @ 2013-11-06 15:51 UTC (permalink / raw)
  To: Eric Paris
  Cc: Andy Lutomirski, Kees Cook, Will Drewry, Richard Weinberger,
	linux-kernel, libseccomp-discuss, linux-arm-kernel

On Wed, Nov 06, 2013 at 10:32:31AM -0500, Eric Paris wrote:
> On Tue, 2013-11-05 at 14:36 -0800, Andy Lutomirski wrote:
> > 1. Set a different audit arch for OABI syscalls (e.g.
> > AUDIT_ARCH_ARMOABI).  That is, treat OABI syscall entries the same way
> > that x86_64 treats int 80.
> 
> As the audit maintainer, I like #1.  It might break ABI, but the ABI is
> flat wrong now and not maintainable...

If you read the whole thread, you will see that this corner case is just
not worth the effort to support.  Audit may as well be disabled by
kernel config if any OABI support is enabled.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls
  2013-11-06 15:51   ` Russell King - ARM Linux
@ 2013-11-06 21:20     ` Will Drewry
  2013-11-06 21:26       ` Kees Cook
  0 siblings, 1 reply; 16+ messages in thread
From: Will Drewry @ 2013-11-06 21:20 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Eric Paris, Andy Lutomirski, Kees Cook, Richard Weinberger,
	linux-kernel, libseccomp-discuss, linux-arm-kernel

On Wed, Nov 6, 2013 at 9:51 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Nov 06, 2013 at 10:32:31AM -0500, Eric Paris wrote:
>> On Tue, 2013-11-05 at 14:36 -0800, Andy Lutomirski wrote:
>> > 1. Set a different audit arch for OABI syscalls (e.g.
>> > AUDIT_ARCH_ARMOABI).  That is, treat OABI syscall entries the same way
>> > that x86_64 treats int 80.
>>
>> As the audit maintainer, I like #1.  It might break ABI, but the ABI is
>> flat wrong now and not maintainable...
>
> If you read the whole thread, you will see that this corner case is just
> not worth the effort to support.  Audit may as well be disabled by
> kernel config if any OABI support is enabled.

This might be the best move for seccomp too (as Kees suggested).  I'd
love to have audit arch visibility, but it's not clear that it's worth
any sort of larger changes ...

... like adding a task_thread_info.compat flag that bubbles up to
syscall_get_arch(), or if we assume consumers of syscall_get_nr() are
broken today (I haven't checked), then it would be possible to at
least re-add the 0x900000 bits, if compat, before handing back the
system call number but leave the audit arch pieces alone.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls
  2013-11-06 21:20     ` Will Drewry
@ 2013-11-06 21:26       ` Kees Cook
  2013-11-06 21:49         ` Andy Lutomirski
  2013-11-06 22:17         ` Russell King - ARM Linux
  0 siblings, 2 replies; 16+ messages in thread
From: Kees Cook @ 2013-11-06 21:26 UTC (permalink / raw)
  To: Will Drewry
  Cc: Russell King - ARM Linux, Eric Paris, Andy Lutomirski,
	Richard Weinberger, linux-kernel, libseccomp-discuss,
	linux-arm-kernel

On Wed, Nov 6, 2013 at 1:20 PM, Will Drewry <wad@chromium.org> wrote:
> On Wed, Nov 6, 2013 at 9:51 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Wed, Nov 06, 2013 at 10:32:31AM -0500, Eric Paris wrote:
>>> On Tue, 2013-11-05 at 14:36 -0800, Andy Lutomirski wrote:
>>> > 1. Set a different audit arch for OABI syscalls (e.g.
>>> > AUDIT_ARCH_ARMOABI).  That is, treat OABI syscall entries the same way
>>> > that x86_64 treats int 80.
>>>
>>> As the audit maintainer, I like #1.  It might break ABI, but the ABI is
>>> flat wrong now and not maintainable...
>>
>> If you read the whole thread, you will see that this corner case is just
>> not worth the effort to support.  Audit may as well be disabled by
>> kernel config if any OABI support is enabled.
>
> This might be the best move for seccomp too (as Kees suggested).  I'd
> love to have audit arch visibility, but it's not clear that it's worth
> any sort of larger changes ...
>
> ... like adding a task_thread_info.compat flag that bubbles up to
> syscall_get_arch(), or if we assume consumers of syscall_get_nr() are
> broken today (I haven't checked), then it would be possible to at
> least re-add the 0x900000 bits, if compat, before handing back the
> system call number but leave the audit arch pieces alone.

How does this look, for the seccomp part?

-Kees

diff --git a/arch/Kconfig b/arch/Kconfig
index af2cc6eabcc7..3610c2d9910f 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -331,7 +331,7 @@ config HAVE_ARCH_SECCOMP_FILTER

 config SECCOMP_FILTER
        def_bool y
-       depends on HAVE_ARCH_SECCOMP_FILTER && SECCOMP && NET
+       depends on HAVE_ARCH_SECCOMP_FILTER && SECCOMP && NET && !OABI_COMPAT
        help
          Enable tasks to build secure computing environments defined
          in terms of Berkeley Packet Filter programs which implement


-- 
Kees Cook
Chrome OS Security

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* Re: [libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls
  2013-11-06 21:26       ` Kees Cook
@ 2013-11-06 21:49         ` Andy Lutomirski
  2013-11-06 22:17         ` Russell King - ARM Linux
  1 sibling, 0 replies; 16+ messages in thread
From: Andy Lutomirski @ 2013-11-06 21:49 UTC (permalink / raw)
  To: Kees Cook
  Cc: Will Drewry, Russell King - ARM Linux, Eric Paris,
	Richard Weinberger, linux-kernel, libseccomp-discuss,
	linux-arm-kernel

On Wed, Nov 6, 2013 at 1:26 PM, Kees Cook <keescook@chromium.org> wrote:
> On Wed, Nov 6, 2013 at 1:20 PM, Will Drewry <wad@chromium.org> wrote:
>> On Wed, Nov 6, 2013 at 9:51 AM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>> On Wed, Nov 06, 2013 at 10:32:31AM -0500, Eric Paris wrote:
>>>> On Tue, 2013-11-05 at 14:36 -0800, Andy Lutomirski wrote:
>>>> > 1. Set a different audit arch for OABI syscalls (e.g.
>>>> > AUDIT_ARCH_ARMOABI).  That is, treat OABI syscall entries the same way
>>>> > that x86_64 treats int 80.
>>>>
>>>> As the audit maintainer, I like #1.  It might break ABI, but the ABI is
>>>> flat wrong now and not maintainable...
>>>
>>> If you read the whole thread, you will see that this corner case is just
>>> not worth the effort to support.  Audit may as well be disabled by
>>> kernel config if any OABI support is enabled.
>>
>> This might be the best move for seccomp too (as Kees suggested).  I'd
>> love to have audit arch visibility, but it's not clear that it's worth
>> any sort of larger changes ...
>>
>> ... like adding a task_thread_info.compat flag that bubbles up to
>> syscall_get_arch(), or if we assume consumers of syscall_get_nr() are
>> broken today (I haven't checked), then it would be possible to at
>> least re-add the 0x900000 bits, if compat, before handing back the
>> system call number but leave the audit arch pieces alone.

That would fix the main issue, but I bet that no one will ever do
anything on the userspace side other than treating those syscalls like
any other unknown syscall.

>
> How does this look, for the seccomp part?
>
> -Kees
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index af2cc6eabcc7..3610c2d9910f 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -331,7 +331,7 @@ config HAVE_ARCH_SECCOMP_FILTER
>
>  config SECCOMP_FILTER
>         def_bool y
> -       depends on HAVE_ARCH_SECCOMP_FILTER && SECCOMP && NET
> +       depends on HAVE_ARCH_SECCOMP_FILTER && SECCOMP && NET && !OABI_COMPAT
>         help
>           Enable tasks to build secure computing environments defined
>           in terms of Berkeley Packet Filter programs which implement
>

Works for me.  Of course, I don't maintain any of this stuff, so I
don't have to deal with it :)

It's probably work adding some text either in CONFIG_SECCOMP_FILTER or
CONFIG_OABI_COMPAT explaining what the problem is.


FWIW, does syscall restart work with OABI_COMPAT?  I've never
understood the syscall restart mechanism, but x86 had an issue awhile
back when with sysenter vs. syscall that was kind of similar.

--Andy

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls
  2013-11-06 21:26       ` Kees Cook
  2013-11-06 21:49         ` Andy Lutomirski
@ 2013-11-06 22:17         ` Russell King - ARM Linux
  1 sibling, 0 replies; 16+ messages in thread
From: Russell King - ARM Linux @ 2013-11-06 22:17 UTC (permalink / raw)
  To: Kees Cook
  Cc: Will Drewry, Eric Paris, Andy Lutomirski, Richard Weinberger,
	linux-kernel, libseccomp-discuss, linux-arm-kernel

On Wed, Nov 06, 2013 at 01:26:52PM -0800, Kees Cook wrote:
> On Wed, Nov 6, 2013 at 1:20 PM, Will Drewry <wad@chromium.org> wrote:
> > On Wed, Nov 6, 2013 at 9:51 AM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> >> On Wed, Nov 06, 2013 at 10:32:31AM -0500, Eric Paris wrote:
> >>> On Tue, 2013-11-05 at 14:36 -0800, Andy Lutomirski wrote:
> >>> > 1. Set a different audit arch for OABI syscalls (e.g.
> >>> > AUDIT_ARCH_ARMOABI).  That is, treat OABI syscall entries the same way
> >>> > that x86_64 treats int 80.
> >>>
> >>> As the audit maintainer, I like #1.  It might break ABI, but the ABI is
> >>> flat wrong now and not maintainable...
> >>
> >> If you read the whole thread, you will see that this corner case is just
> >> not worth the effort to support.  Audit may as well be disabled by
> >> kernel config if any OABI support is enabled.
> >
> > This might be the best move for seccomp too (as Kees suggested).  I'd
> > love to have audit arch visibility, but it's not clear that it's worth
> > any sort of larger changes ...
> >
> > ... like adding a task_thread_info.compat flag that bubbles up to
> > syscall_get_arch(), or if we assume consumers of syscall_get_nr() are
> > broken today (I haven't checked), then it would be possible to at
> > least re-add the 0x900000 bits, if compat, before handing back the
> > system call number but leave the audit arch pieces alone.
> 
> How does this look, for the seccomp part?

Looks correct, thanks.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
  2013-11-06  0:14 ` Kees Cook
  2013-11-06  0:40   ` Russell King - ARM Linux
@ 2013-11-06 22:30   ` Matt Sealey
  2013-11-06 22:33     ` Andy Lutomirski
  1 sibling, 1 reply; 16+ messages in thread
From: Matt Sealey @ 2013-11-06 22:30 UTC (permalink / raw)
  To: Kees Cook
  Cc: Andy Lutomirski, Paul Moore, Richard Weinberger,
	libseccomp-discuss, Will Drewry, linux-kernel, linux-arm-kernel,
	Russell King

On Tue, Nov 5, 2013 at 6:14 PM, Kees Cook <keescook@chromium.org> wrote:
>
> Alternatively, CONFIG_SECCOMP_FILTER could depend on
> !CONFIG_OABI_COMPAT. That seems like the least work, given the desire
> to kill OABI in the real world. (Though I would note that at least
> Ubuntu's ARM kernels build with CONFIG_OABI_COMPAT; Chrome OS does
> not.)

I think CONFIG_OABI_COMPAT probably leaked in from the original
configurations of the kernel taken from Debian.

There were several big decisions they made (build for ARMv5 soft
float, then switch to ARMv7 softfp, then switch to ARMv7 hardfp, then
switch to using THUMB2 kernels) which would have just broken OABI
binaries at every step of the way since they had some subtle
implications in kernel configuration (note: Ubuntu have never, ever
enabled FPA emulation in the kernel, and all Debian's OABI userspace
is built for FPA, for example. A good chunk of the original Debian arm
port probably would just pitch a SIGILL if you ran it under an Ubuntu
kernel).

I would ignore anyone who enables it in a distribution, since they
probably weren't intending to enable it in the first place, and never
noticed the.. what.. 3-4KiB it adds to the kernel?

Matt Sealey <neko@bakuhatsu.net>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
  2013-11-06 22:30   ` Matt Sealey
@ 2013-11-06 22:33     ` Andy Lutomirski
  0 siblings, 0 replies; 16+ messages in thread
From: Andy Lutomirski @ 2013-11-06 22:33 UTC (permalink / raw)
  To: Matt Sealey
  Cc: Kees Cook, Paul Moore, Richard Weinberger, libseccomp-discuss,
	Will Drewry, linux-kernel, linux-arm-kernel, Russell King

On Wed, Nov 6, 2013 at 2:30 PM, Matt Sealey <neko@bakuhatsu.net> wrote:
> On Tue, Nov 5, 2013 at 6:14 PM, Kees Cook <keescook@chromium.org> wrote:
>>
>> Alternatively, CONFIG_SECCOMP_FILTER could depend on
>> !CONFIG_OABI_COMPAT. That seems like the least work, given the desire
>> to kill OABI in the real world. (Though I would note that at least
>> Ubuntu's ARM kernels build with CONFIG_OABI_COMPAT; Chrome OS does
>> not.)
>
> I think CONFIG_OABI_COMPAT probably leaked in from the original
> configurations of the kernel taken from Debian.
>
> There were several big decisions they made (build for ARMv5 soft
> float, then switch to ARMv7 softfp, then switch to ARMv7 hardfp, then
> switch to using THUMB2 kernels) which would have just broken OABI
> binaries at every step of the way since they had some subtle
> implications in kernel configuration (note: Ubuntu have never, ever
> enabled FPA emulation in the kernel, and all Debian's OABI userspace
> is built for FPA, for example. A good chunk of the original Debian arm
> port probably would just pitch a SIGILL if you ran it under an Ubuntu
> kernel).
>
> I would ignore anyone who enables it in a distribution, since they
> probably weren't intending to enable it in the first place, and never
> noticed the.. what.. 3-4KiB it adds to the kernel?
>

Forget the size -- it adds a fair amount of complexity and a D-cache
miss on every syscall.

--Andy

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
  2013-11-06  3:22     ` Andy Lutomirski
@ 2013-11-07 12:55       ` Henrique de Moraes Holschuh
  2013-11-07 17:54         ` Kees Cook
  0 siblings, 1 reply; 16+ messages in thread
From: Henrique de Moraes Holschuh @ 2013-11-07 12:55 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Russell King - ARM Linux, Kees Cook, Paul Moore,
	Richard Weinberger, libseccomp-discuss, Will Drewry,
	linux-kernel, linux-arm-kernel

On Tue, 05 Nov 2013, Andy Lutomirski wrote:
> Maybe the thing to do is to put a warning in the config text for
> CONFIG_OABI_COMPAT that describes the problems (malicious userspace
> can confuse syscall auditors, strace, etc.), change the "if in doubt"
> part to N, and disable seccomp filters if CONFIG_OABI_COMPAT.  That
> might even get Debian to change their default.

Bug reported to the Debian BTS: #728975
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728975

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
  2013-11-07 12:55       ` Henrique de Moraes Holschuh
@ 2013-11-07 17:54         ` Kees Cook
  2013-11-07 19:04           ` Henrique de Moraes Holschuh
  0 siblings, 1 reply; 16+ messages in thread
From: Kees Cook @ 2013-11-07 17:54 UTC (permalink / raw)
  To: Henrique de Moraes Holschuh
  Cc: Andy Lutomirski, Russell King - ARM Linux, Paul Moore,
	Richard Weinberger, libseccomp-discuss, Will Drewry,
	linux-kernel, linux-arm-kernel

On Thu, Nov 7, 2013 at 4:55 AM, Henrique de Moraes Holschuh
<hmh@hmh.eng.br> wrote:
> On Tue, 05 Nov 2013, Andy Lutomirski wrote:
>> Maybe the thing to do is to put a warning in the config text for
>> CONFIG_OABI_COMPAT that describes the problems (malicious userspace
>> can confuse syscall auditors, strace, etc.), change the "if in doubt"
>> part to N, and disable seccomp filters if CONFIG_OABI_COMPAT.  That
>> might even get Debian to change their default.
>
> Bug reported to the Debian BTS: #728975
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728975

FWIW, Ubuntu has also now disabled OABI_COMPAT going forward:
https://lists.ubuntu.com/archives/kernel-team/2013-November/034242.html

-Kees

-- 
Kees Cook
Chrome OS Security

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
  2013-11-07 17:54         ` Kees Cook
@ 2013-11-07 19:04           ` Henrique de Moraes Holschuh
  0 siblings, 0 replies; 16+ messages in thread
From: Henrique de Moraes Holschuh @ 2013-11-07 19:04 UTC (permalink / raw)
  To: Kees Cook
  Cc: Andy Lutomirski, Russell King - ARM Linux, Paul Moore,
	Richard Weinberger, libseccomp-discuss, Will Drewry,
	linux-kernel, linux-arm-kernel

On Thu, 07 Nov 2013, Kees Cook wrote:
> On Thu, Nov 7, 2013 at 4:55 AM, Henrique de Moraes Holschuh
> <hmh@hmh.eng.br> wrote:
> > On Tue, 05 Nov 2013, Andy Lutomirski wrote:
> >> Maybe the thing to do is to put a warning in the config text for
> >> CONFIG_OABI_COMPAT that describes the problems (malicious userspace
> >> can confuse syscall auditors, strace, etc.), change the "if in doubt"
> >> part to N, and disable seccomp filters if CONFIG_OABI_COMPAT.  That
> >> might even get Debian to change their default.
> >
> > Bug reported to the Debian BTS: #728975
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728975
> 
> FWIW, Ubuntu has also now disabled OABI_COMPAT going forward:
> https://lists.ubuntu.com/archives/kernel-team/2013-November/034242.html

Unless something very weird happens, it looks like that's also what Debian
will do.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2013-11-07 19:04 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-05 22:36 ARM audit, seccomp, etc are broken wrt OABI syscalls Andy Lutomirski
2013-11-06  0:14 ` Kees Cook
2013-11-06  0:40   ` Russell King - ARM Linux
2013-11-06  3:22     ` Andy Lutomirski
2013-11-07 12:55       ` Henrique de Moraes Holschuh
2013-11-07 17:54         ` Kees Cook
2013-11-07 19:04           ` Henrique de Moraes Holschuh
2013-11-06  9:52     ` Mikael Pettersson
2013-11-06 22:30   ` Matt Sealey
2013-11-06 22:33     ` Andy Lutomirski
2013-11-06 15:32 ` [libseccomp-discuss] " Eric Paris
2013-11-06 15:51   ` Russell King - ARM Linux
2013-11-06 21:20     ` Will Drewry
2013-11-06 21:26       ` Kees Cook
2013-11-06 21:49         ` Andy Lutomirski
2013-11-06 22:17         ` Russell King - ARM Linux

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).