SIGSYS on statfs in coreutils

[Vladislav Kuzkokov]

I was using a python script to emulate a printer based on platform_AddPrinter test:

https://chromium.googlesource.com/chromiumos/third_party/autotest/+/master/client/site_tests/platform_AddPrinter

This worked until about 2-3 weeks ago. Now I get a crash.

My suspicion is that something has changed recently in SELinux policies.

How do I track this down?

Here's the trace for 10191 canary build:

Crash reason:  SIGSYS

Crash address: 0x0

Process uptime: not available

Thread 0 (crashed)

 0  libc-2.23.so!__statfs + 0x7

     r0 = 0xb522ab0c    r1 = 0xbeef49f8    r2 = 0xb522e8d4    r3 = 0x0001aaa8

     r4 = 0xb522ab0c    r5 = 0xbeef49f8    r6 = 0x00000003    r7 = 0x00000063

     r8 = 0xbeef4ab4    r9 = 0x00000000   r10 = 0xb522daa8   r12 = 0xb522de28

     fp = 0x00000000    sp = 0xbeef49a4    lr = 0xb521e24d    pc = 0xb5174318

    Found by: given as instruction pointer in context

 1  libselinux.so.1!init_lib [init.c : 38 + 0x7]

     r4 = 0xb522ab0c    r5 = 0xbeef49f8    r6 = 0x00000003    r7 = 0xbeef4a58

     r8 = 0xbeef4ab4    r9 = 0x00000000   r10 = 0xb522daa8    fp = 0x00000000

     sp = 0xbeef49a8    pc = 0xb521e24d

    Found by: call frame info

 2  ld-2.23.so!call_init [dl-init.c : 72 + 0x5]

     r4 = 0x00000002    r5 = 0xb521e209    r6 = 0x00000003    r7 = 0xbeef4aa4

     r8 = 0xbeef4ab4    r9 = 0x00000002   r10 = 0xb522daa8    fp = 0x00000000

     sp = 0xbeef4a60    pc = 0xb523baa5

    Found by: call frame info

 3  ld-2.23.so!_dl_init [dl-init.c : 30 + 0x11]

     r4 = 0x00000000    r5 = 0x00000001    r6 = 0x00000003    r7 = 0xbeef4aa4

     r8 = 0xbeef4ab4    r9 = 0xb5258908   r10 = 0x00000000    fp = 0x00000000

     sp = 0xbeef4a80    pc = 0xb523bb83

    Found by: call frame info

 4  ld-2.23.so!_dl_start_user + 0x22

     r4 = 0x00000000    r5 = 0x00000000    r6 = 0x0a5327b1    r7 = 0x00000000

     r8 = 0x00000000    r9 = 0x00000000   r10 = 0xb5257fb0    fp = 0x00000000

     sp = 0xbeef4aa0    pc = 0xb5230ab3

[Mike Frysinger]

SELinux currently only applies to code running inside ARC++.  if you aren't in there, then its rules don't apply.

that said, i don't think there are any rules which would trigger a SIGSYS ... that tends to be generated when a seccomp policy is violated.  your crash doesn't indicate what process is actually failing, so you should look at that to see what its seccomp rules it's using, and make sure that statfs is whitelisted in it.

-mike

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

[Vladislav Kuzkokov]

On Tuesday, December 12, 2017 at 3:54:39 PM UTC+1, Mike Frysinger wrote:

SELinux currently only applies to code running inside ARC++.  if you aren't in there, then its rules don't apply.

that said, i don't think there are any rules which would trigger a SIGSYS ... that tends to be generated when a seccomp policy is violated.  your crash doesn't indicate what process is actually failing,

That's part of tracking it down. I only know for sure that it's coreutils. My guess is that's "/bin/cat" which is used instead of printing renderer.

so you should look at that to see what its seccomp rules it's using, and make sure that statfs is whitelisted in it.

Do you know where I can look them up? 

[Mike Frysinger]

you seem to have a crash report already right ?  that should have the process name in it and the associated program.

-mike

[Vladislav Kuzkokov]

On Tuesday, December 12, 2017 at 5:12:23 PM UTC+1, Mike Frysinger wrote:

you seem to have a crash report already right ?  that should have the process name in it and the associated program.

I have coreutils.20171208.153646.5205.core, .dmp and .meta. Does that count?

[Vladislav Kuzkokov]

I clobbered state and flashed 10205 test image which has crbug.com/791395 fixed, so I have a simpler repro now:

(chroot)$ test_that --board=$BOARD minnie platform_AddPrinter.generic

The trace is only slightly different:

Operating system: Linux

                  0.0.0 Linux 3.14.0 #1 SMP PREEMPT Mon Dec 11 03:25:31 PST 2017 armv7l

CPU: arm

     ARMv1 ARM part(0x4100c0d0) features: swp,half,thumb,fastmult,vfpv2,edsp,thumbee,neon,vfpv3,tls,vfpv4,idiva,idivt

     4 CPUs

GPU: UNKNOWN

Crash reason:  SIGSYS

Crash address: 0x0

Process uptime: not available

Thread 0 (crashed)

 0  libc-2.23.so!__statfs + 0x7

     r0 = 0xaee21b0c    r1 = 0xbed16a48    r2 = 0xaee258d4    r3 = 0x0001aaa8

     r4 = 0xaee21b0c    r5 = 0xbed16a48    r6 = 0x00000003    r7 = 0x00000063

     r8 = 0xbed16b04    r9 = 0x00000000   r10 = 0xaee24aa8   r12 = 0xaee24e28

     fp = 0x00000000    sp = 0xbed169f4    lr = 0xaee1524d    pc = 0xaed6b318

    Found by: given as instruction pointer in context

 1  libselinux.so.1!init_lib [init.c : 38 + 0x7]

     r4 = 0xaee21b0c    r5 = 0xbed16a48    r6 = 0x00000003    r7 = 0xbed16aa8

     r8 = 0xbed16b04    r9 = 0x00000000   r10 = 0xaee24aa8    fp = 0x00000000

     sp = 0xbed169f8    pc = 0xaee1524d

    Found by: call frame info

 2  ld-2.23.so!call_init [dl-init.c : 72 + 0x5]

     r4 = 0x00000002    r5 = 0xaee15209    r6 = 0x00000003    r7 = 0xbed16af4

     r8 = 0xbed16b04    r9 = 0x00000002   r10 = 0xaee24aa8    fp = 0x00000000

     sp = 0xbed16ab0    pc = 0xaee32aa5

    Found by: call frame info

 3  ld-2.23.so!_dl_init [dl-init.c : 30 + 0x11]

     r4 = 0x00000000    r5 = 0x00000001    r6 = 0x00000003    r7 = 0xbed16af4

     r8 = 0xbed16b04    r9 = 0xaee4f908   r10 = 0x00000000    fp = 0x00000000

     sp = 0xbed16ad0    pc = 0xaee32b83

    Found by: call frame info

 4  ld-2.23.so!_dl_start_user + 0x22

     r4 = 0x00000000    r5 = 0x00000000    r6 = 0x07bb87b1    r7 = 0x00000000

     r8 = 0x00000000    r9 = 0x00000000   r10 = 0xaee4efb0    fp = 0x00000000

     sp = 0xbed16af0    pc = 0xaee27ab3

    Found by: call frame info

Loaded modules:

0x07bb1000 - 0x07c83fff  coreutils  ???  (main)

0xaec66000 - 0xaec67fff  libdl-2.23.so  ???

0xaec79000 - 0xaecdcfff  libpcre.so.1.2.8  ???

0xaecdf000 - 0xaedb5fff  libc-2.23.so  ???  (WARNING: Corrupt symbols, libc-2.23.so, 8AF5017EA5591D2A20559931B0444B6D0)

0xaedcc000 - 0xaeddbfff  libpthread-2.23.so  ???

0xaedef000 - 0xaedf3fff  librt-2.23.so  ???

0xaee05000 - 0xaee07fff  libattr.so.1.1.0  ???

0xaee0a000 - 0xaee23fff  libselinux.so.1  ???

0xaee27000 - 0xaee3efff  ld-2.23.so  ???

[Mike Frysinger]

that is a coreutils program.  if you look at the .core or .dmp it'll tell you the full command line.  simply running `strings` on either should give you output you can track down.

then find the program that actually ran it.  that's not as easy ... but since you know you're looking at printer code, you can focus on the cups daemons that we've sandboxed.  once you know the daemon, you can see how it's sandboxing programs.

-mike

[Vladislav Kuzkokov]

As I suspected it is /bin/cat.

I suggest moving this to crbug.com/791395 which is reopened because of this failure.