Join GitHub today
Add kernel builder script #6
Based in comments from kata-containers/linux#5 we may want:
What kernel formats we want to support ?
I consider vmlinux and vmlinuz (compressed and decompressed)
Do we want to support for kernel modules ?
IMO the kata kernel should not ship modules, all the need features would be built-in. This will make easy use the kernel independently of the guest image.
Here I have in mind two ways:
Then build the kernel:
This will build the downloaded and configured kernel from
We discussed that somewhat already didn't we @bergwolf over at: kata-containers/linux#5 (comment)
I know @mcastelino and I think @egernst would also like module support - and I have no real objection to enabling it as long as we have some plan/mitigation to help avert users from trying to load the wrong modules, which could then cause us many painful debug headaches :-)
@grahamwhaley yes we did and it seems we have not reached an agreement. We can enable module crc to have a minimal checking, or enable module signing if we care that much.
We should ship a list of modules we want to support and users are supposed to use them only. Users are responsible for their own actions inside a container and pay if they install a hacked module other than the ones provided by us. At the least, whatever modules loaded by a user only affect one guest.
I think we can break this down into a couple of stages/decisions...
Collecting information about it modules discussion:
I see two points:
For the list of modules to build by default, let's collate the needs from both CC and runv.
Then we can enable
referenced this issue
Jun 21, 2018
After the kernel config wiki page was created:
... I started looking at the kernel configs we currently have in the packaging repo:
... and I found the following (which I'm assuming was an oversight):
osbuilder creates a YAML file inside the image with details about the image. I'm wondering if we want to do something similar for the assets that live outside the image, one of which is the kernel. We could create something like:
These files wouldn't need to be consumed by the runtime but would be useful for admins / developers.
What's annoying is that I can't see a way to check if a particular pair of files (kernel yaml + image yaml) are compatible. I think the best we could do is get osbuilder to generate a random hash and embed that into both YAML files so you'd atleast know that the pair were build as part of the same osbuilder run (and where tested together and hence should be compatible). Something like having the following in both files: