containers can load a kernel to kexec
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
High
|
Stefan Bader | ||
Precise |
Fix Released
|
Undecided
|
Stefan Bader | ||
Quantal |
Fix Released
|
High
|
Stefan Bader | ||
lxc (Ubuntu) |
Invalid
|
High
|
Unassigned | ||
Precise |
Won't Fix
|
Undecided
|
Unassigned | ||
Quantal |
Won't Fix
|
High
|
Unassigned |
Bug Description
Loading a kexec kernel is guarded by CAP_SYS_BOOT, which we allow a container to have.
A container can't do 'kexec -e' to actually execute the new kernel, because that requires a call to reboot which is refused. However, it can do kexec -l do load a kernel for the next kexec -e. This means that it could race with an admin on the host doing 'kexec -l; kexec -e'. Exact command line used in the container (after
copying /boot/* from the host to /var/lib/
sudo kexec -l /boot/vmlinuz-
Before this, kexec -e on the host gives:
Nothing has been loaded!
After this, it loads the new kernel.
There is a patch on lkml to prevent a task in non-init pid namespace (i.e. a container) from loading kexec kernels: https:/
After quantal, user namespaces will provide an alternative fix.
description: | updated |
Changed in lxc (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → High |
Changed in linux (Ubuntu): | |
importance: | Undecided → High |
tags: | added: kernel-key |
Changed in linux (Ubuntu): | |
assignee: | nobody → Stefan Bader (stefan-bader-canonical) |
status: | Triaged → Fix Committed |
Changed in linux (Ubuntu Precise): | |
assignee: | nobody → Stefan Bader (stefan-bader-canonical) |
status: | New → Fix Committed |
Changed in lxc (Ubuntu Quantal): | |
status: | Triaged → Invalid |
Changed in lxc (Ubuntu Precise): | |
status: | New → Invalid |
status: | Invalid → Won't Fix |
Changed in lxc (Ubuntu Quantal): | |
status: | Invalid → Won't Fix |
This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:
apport-collect 1034125
and then change the status of the bug to 'Confirmed'.
If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.
This change has been made by an automated script, maintained by the Ubuntu Kernel Team.