21:16 < lool> kees: Around?  Do you think you'd know what could cause 364290?
21:17 < kees> lool: sounds like the kernel is forcing PROT_EXEC for mmap calls.
21:17 < lool> kees: Could it be a kernel config?
21:17 < kees> lool: we faced that on i386 when init was set to have an executable stack
21:17 < kees> lool: it's likely the way in which you transition to init from the boot process.
21:18 < kees> lool: in normal Ubuntu, we use klibc to exec upstart, how does ARM do it?
21:18 < lool> kees: In theory in the same way
21:18 < lool> kees: Not quite sure we use klibc though, it could be regular libc
21:19 < lool> kees: Checking...
21:20 < lool> kees: Will take a while, will come back to you when it's booted
21:20 < lool> kees: thanks!
21:21 < kees> lool: okay, in the meantime, I'm hunting the fixes for klibc that I got upstreamed
21:22 < kees> lool: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commitdiff;h=812e2ff7e74e8c495c936981ba0a0372e50b7244
21:24 < kees> lool: what does   sudo cat /proc/1/personality   say ?
21:29 < lool> kees: 00c00000
21:29 < kees> lool: yeah, looks like READ_IMPLIES_EXEC is getting set (this should not be)
21:29 < kees> lool: I would have expected 00000000
21:30 < kees> lool: /proc/$pid/personality exists because I spent so long debugging this issue on ia32.  ;)
21:30 < lool> kees: I can confirm that /sbin/init uses libc; /lib/vfp/libc actually
21:31 < kees> lool: /sbin/init in the boot setup, right? not upstart itself?
21:31 < kees> lool: does your local shell have 00000000 personality?
21:31 < lool> kees: Sorry, I'm just saying PID 1 uses /lib/vfp/libc
21:32 < lool> kees: Yes
21:32 < lool> kees: sudo cat /proc/self/personality returns 00c00000
21:33 < kees> lool: hrm, so all the processes have 00c00000 ?  that would seem to imply that ARM architecture doesn't have NX protections
21:35 < lool> kees: Perhaps it doesn't; how could I check?
21:35 < lool> kees: In which case we should disable AA?
21:36 < kees> lool: can you paste /proc/cpuinfo somewhere for me?
21:36 < kees> lool: disabling AA on ARM seems unfortunate.
21:37 < lool> kees: we're moving to v6 next cycle
21:37 < kees> lool: I was hoping someone could run the regression tester I wrote on an ARM image: http://people.ubuntu.com/~kees/qrt-test-kernel-security.tar.gz
21:38 < lool> kees: http://pastebin.com/f147ffe7c
21:43 < kees> lool: what does   readelf -l /sbin/init   show ?
21:44 < kees> lool: (specifically interested in GNU_STACK item, and if it says "RW" or "RWE")
21:45 < kees> lool: okay, so the executable itself isn't marked as needing an executable stack, so it must be coming from the kernel side
21:47 < kees> lool: interesting, the personality flags map to READ_IMPLIES_EXEC and ADDR_LIMIT_32BIT
21:49 < kees> lool: so, near as I can tell, the kernel's arm_elf_read_implies_exec is returning "1", and the executable_stack is correctly set to EXSTACK_DISABLE_X (via the ELF headers)
21:50 < kees> lool: the only way that can happen is:
21:53 < kees> lool: according to your /proc/cpuinfo, you've got CPU_ARCH_ARMv5TEJ not CPU_ARCH_ARMv7
21:53 < kees> lool: "CPU architecture: 7" vs arch/arm/include/asm/system.h
21:54 < kees> lool: though I find it interesting that arch/arm/kernel/setup.c does not have CPU_ARCH_ARMv5TEJ mentioned
21:55 < kees> lool: I take it back, you *do* have CPU_ARCH_ARMv7
21:56 < kees> lool: the /proc/cpuinfo file would say 5TEJ if that's the type you had.  :)
21:56 < kees> lool: so, I'm back around to execstack settings.
21:56 < kees> lool: let me write a READ_IMPLIES_EXEC test for you, one sec...
21:59 < lool> kees: The platform is v7 and the kernel targets that, but the userspace is v5t, sorry for not being clearer
22:00 < kees> lool: so after you've logged in via gdm, your /proc/self/personality still shows 00c00000 ?
22:00 < lool> kees: I was logged in via gdm all the time
22:02 < kees> lool: does cups actually run, or is AA fully blocking it?
22:02 < lool> kees: I see a process at least
22:03 < kees> lool: did you get a chance to run the qrt script I gave a URL to?
22:04 < lool> kees: Oh no missed it
22:04 < kees> 21:37 < kees> lool: I was hoping someone could run on an ARM image the regression tester I wrote: http://people.ubuntu.com/~kees/qrt-test-kernel-security.tar.gz
22:05 < kees> lool: you'll need python-unit, lsb-release, and build-essential, and libcap-bin
22:06 < lool> kees: Does it output a log or will you want stdout?
22:07 < kees> lool: it spews to stdout.  once unpacked:   ./test-kernel-security.py -v
22:07 < kees> lool: you can just pastebin it
22:14 < lool> kees: Sorry netsplit http://paste.ubuntu.com/154988/
22:15 < lool> kees: note that CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR needs to be <= 32768 on arm
22:15 < kees> lool: correct, though that should be unrelated
22:17 < kees> lool: holy crap, there are a lot of missing kernel config options.
22:17 < kees> lool: these should be turned on: CONFIG_DEBUG_RODATA, CONFIG_STRICT_DEVMEM
22:18 < lool> kees: See, I knew we were missing some options; it's been a consistent source of bugs, so I had a good change betting on that   ;-)
22:23 < kees> lool: wow, no randomization in the kernel memory either.  that's sad (that's an upstream deficiency)