Android SELinux fork shouldn't cause init to die on upstream kernels |
|||
Issue descriptionIf I boot an upstream kernel on an ARC++-enabled Chromebook, the init system dies, like this: [ 6.034809] SELinux: avtab: invalid type or class SELinux: Could not load policy file /etc/selinux/arc/policy/policy.30: Invalid argument init: SELinux policy failed to load init: Failed to initialize SELinux: Failed to load SELinux policy while in enforcing mode [ 6.142158] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 [ 6.142158] [ 6.151298] CPU: 0 PID: 1 Comm: init Not tainted 4.10.0+ #414 [ 6.157041] Hardware name: Google Kevin (DT) [ 6.161308] Call trace: [ 6.163776] [<ffffff900808ae58>] dump_backtrace+0x0/0x2b8 [ 6.169180] [<ffffff900808b130>] show_stack+0x20/0x28 [ 6.174237] [<ffffff900846d7dc>] dump_stack+0xa4/0xcc [ 6.179293] [<ffffff90081f13c8>] panic+0x16c/0x2c0 [ 6.184090] [<ffffff90080af520>] do_exit+0x74c/0xdc0 [ 6.189059] [<ffffff90080b1410>] do_group_exit+0x80/0x110 [ 6.194461] [<ffffff90080b14c4>] __wake_up_parent+0x0/0x48 [ 6.199950] [<ffffff9008082f30>] el0_svc_naked+0x24/0x28 [ 6.205258] SMP: stopping secondary CPUs [ 6.209188] Kernel Offset: disabled [ 6.212677] Memory Limit: none Currently, this can be worked around, e.g., by adding 'enforcing=0' to the kernel command line. But this isn't ideal; typically we expect to be able to get some basic features working simply by swapping out an upstream kernel source tree for the CrOS kernel source. Can we make the boot sequence smarter? Is it possible to use upstream SELinux to support ARC++? Or can ARC++ abort gracefully if its rules can't load?
,
Mar 2 2017
Typically we don't change any USE flags or modify the rootfs; just checkout a different kernel source tree, then use a normal workflow (e.g., emerge + update_kernel.sh) which then falls back to the kernel configs in 'chromiumos-overlay/eclass/cros-kernel/*'. I do note that rockchip_defconfig has a CONFIG_CMDLINE set, so maybe we could add enforcing=0 to that and other relevant configs (e.g., rockchip64_defconfig).
,
Mar 2 2017
Re c#1, is that the patch that makes SELinux only enforce inside the container?
,
Mar 2 2017
Re c#3: Ah actually that might be a patch that's missing in the 4.10 kernel: It makes Android SELinux compatible with upstream kernels. briannorris@, does it load correctly with that patch applied? I heavily suspect we want that change in anyways.
,
Mar 2 2017
Ah yeah -- I'm not sure if the Android SELinux implementation would work with an upstream kernel. I know the ioctl stuff was uploaded but I don't know if other stuff was as well.
,
Mar 7 2017
Yes, cherry-picking commit 969f47d4b1986f2950ebfdba90012da60c2aab48 makes things work. But that's not heading upstream, according to comment #1, so it doesn't really help.
,
Mar 7 2017
Will this problem go away once we switch all boards to N?
,
Apr 10 2017
,
May 12 2017
FWIW, I got around to testing this finally. After switching to the N container, Kevin can boot upstream 4.12-rc (well rc1 is not even cut yet; but mid-merge window, we have what we need). Whoo! |
|||
►
Sign in to add a comment |
|||
Comment 1 by lhchavez@chromium.org
, Mar 2 2017