agent: support debug console#547
Conversation
|
/test |
grahamwhaley
left a comment
There was a problem hiding this comment.
lgtm
I'm happy with the way you have to both set it on the kernel line and have a shell in the VM, as that makes it feel less of a potential security hole to me.
I wonder if we can have a CI test to check this works - as this is one of the features that gets used so infrequently, but is so desirable when you need it, and it has a tendency to bitrot...
|
kata-containers/osbuilder#96 is already open for one avenue to test ;) |
jodh-intel
left a comment
There was a problem hiding this comment.
Sweet! Just a query about console perms and a nit ;)
0b8281a to
818951f
Compare
|
@grahamwhaley @jodh-intel changes applied, thanks |
|
/test |
818951f to
5f25782
Compare
|
/test |
Start a debug console if the `agent.debug_console` option is part of the kernel command line and a shell (bash or sh) is installed in the rootfs. The debug console is useful when the developer wants to debug the agent process or any other processes (even containers). The current way to do this is by modifying a systemd target + creating a new system unit, the problem with this approach is that it's not user-friendly and we depend on systemd, since it must be installed in the rootfs. fixes kata-containers#546 Signed-off-by: Julio Montes <julio.montes@intel.com>
5f25782 to
0af7173
Compare
|
/test |
|
@devimc - guess we should check why 18.04-initrd and sles CIs failed? |
|
intird sles nothing related to this pr, restarting CIs |
mcastelino
left a comment
There was a problem hiding this comment.
LGTM. Really waiting for this PR to land.
Now if we add a minimal shell by default the the kata image it would be really helpful.
Some containers may require HW devices to improve its performance. In Kata containers these devices can be passed though VFIO and used in the container only if the guest kernel has the drivers built-in for them. When kernel fragment support landed (kata-containers/packaging#646), kata lost support for several HW devices like Intel GPUs, this was expected since one of the goals of this change was to have a minimal kernel in order to improve boot time, memory footprint and reduce the attack surface by enabling just the features required to run kata containers. Currently if the users want to use a HW device in kata container, He/She has to build a custom kernel and create a custom image that includes the modules that will be loaded by systemd. From user's perspective this is a pain, since not all users know how to create a custom image or configure/build a custom kernel. Same as the `debug_console` feature (kata-containers#547), the goal of this change is to facilitate the things to the final user and *do not* depend on systemd. fixes kata-containers#615 see kata-containers/osbuilder#77 Signed-off-by: Julio Montes <julio.montes@intel.com>
Some containers may require HW devices to improve its performance. In Kata containers these devices can be passed though VFIO and used in the container only if the guest kernel has the drivers built-in for them. When kernel fragment support landed (kata-containers/packaging#646), kata lost support for several HW devices like Intel GPUs, this was expected since one of the goals of this change was to have a minimal kernel in order to improve boot time, memory footprint and reduce the attack surface by enabling just the features required to run kata containers. Currently if the users want to use a HW device in kata container, He/She has to build a custom kernel and create a custom image that includes the modules that will be loaded by systemd. From user's perspective this is a pain, since not all users know how to create a custom image or configure/build a custom kernel. Same as the `debug_console` feature (kata-containers#547), the goal of this change is to facilitate the things to the final user and *do not* depend on systemd. fixes kata-containers#615 see kata-containers/osbuilder#77 Signed-off-by: Julio Montes <julio.montes@intel.com>
Some containers may require HW devices to improve its performance. In Kata containers these devices can be passed though VFIO and used in the container only if the guest kernel has the drivers built-in for them. When kernel fragment support landed (kata-containers/packaging#646), kata lost support for several HW devices like Intel GPUs, this was expected since one of the goals of this change was to have a minimal kernel in order to improve boot time, memory footprint and reduce the attack surface by enabling just the features required to run kata containers. Currently if the users want to use a HW device in kata container, He/She has to build a custom kernel and create a custom image that includes the modules that will be loaded by systemd. From user's perspective this is a pain, since not all users know how to create a custom image or configure/build a custom kernel. Same as the `debug_console` feature (kata-containers#547), the goal of this change is to facilitate the things to the final user and *do not* depend on systemd. The list of kernel modules and their options are set through gRPC when the sandbox is created. fixes kata-containers#615 see kata-containers/osbuilder#77 Signed-off-by: Julio Montes <julio.montes@intel.com>
Some containers may require HW devices to improve its performance. In Kata containers these devices can be passed though VFIO and used in the container only if the guest kernel has the drivers built-in for them. When kernel fragment support landed (kata-containers/packaging#646), kata lost support for several HW devices like Intel GPUs, this was expected since one of the goals of this change was to have a minimal kernel in order to improve boot time, memory footprint and reduce the attack surface by enabling just the features required to run kata containers. Currently if the users want to use a HW device in kata container, He/She has to build a custom kernel and create a custom image that includes the modules that will be loaded by systemd. From user's perspective this is a pain, since not all users know how to create a custom image or configure/build a custom kernel. Same as the `debug_console` feature (kata-containers#547), the goal of this change is to facilitate the things to the final user and *do not* depend on systemd. The list of kernel modules and their parameters are set through gRPC when the sandbox is created. fixes kata-containers#615 see kata-containers/osbuilder#77 Signed-off-by: Julio Montes <julio.montes@intel.com>
Start a debug console if the
agent.debug_consoleoption is part of the kernelcommand line and a shell (bash or sh) is installed in the rootfs.
The debug console is useful when the developer wants to debug the agent process
or any other processes (even containers). The current way to do this is by
modifying a systemd target + creating a new system unit, the problem with this
approach is that it's not user-friendly and we depend on systemd, since it must
be installed in the rootfs.
fixes #546
Signed-off-by: Julio Montes julio.montes@intel.com