Linux v6.16 brings some useful features for the confidential guests. Most importantly, it adds an ABI to extend runtime measurement registers (RTMR) for the TEE platforms supporting it. This is currently enabled on Intel TDX only. The kernel version bump from v6.12.x to v6.16 forces some CONFIG_* changes too: MEMORY_HOTPLUG_DEFAULT_ONLINE was dropped in favor of more config choices. The equivalent option is MHP_DEFAULT_ONLINE_TYPE_ONLINE_AUTO. X86_5LEVEL was made unconditional. Since this was only a TDX configuration, dropping it completely as part of v6.16 is fine. CRYPTO_NULL2 was merged with CRYPTO_NULL. This was only added in confidential guest fragments (cryptsetup) so we can drop it in this update. CRYPTO_FIPS now depends on CRYPTO_SELFTESTS which further depends on EXPERT which we don't have. Enable both in a separate config fragment for confidential guests. This can be moved to a common setting once other targets bump to post v6.16. CRYPTO_SHA256_SSE3 arch optimizations were reworked and are now enabled by default. Instead of adding it to whitelist.conf, just drop it completely since it was only enabled as part of "measured boot" feature for confidential guests. CONFIG_CRYPTO_CRC32_S390 was reworked the same way. In this case, whitelist.conf is needed. Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>
Kata Containers kernel config files
This directory contains Linux Kernel config files used to configure Kata Containers VM kernels.
Types of config files
This directory holds config files for the Kata Linux Kernel in two forms:
- A tree of config file
fragmentsin thefragmentssub-folder, that are constructed into a complete config file using the kernelscripts/kconfig/merge_config.shscript. - As complete config files that can be used as-is.
Kernel config fragments are the preferred method of constructing .config files
to build Kata Containers kernels, due to their improved clarity and ease of maintenance
over single file monolithic .configs.
How to use config files
The recommended way to set up a kernel tree, populate it with a relevant .config file,
and build a kernel, is to use the build_kernel.sh script. For
example:
$ ./build-kernel.sh setup
The build-kernel.sh script understands both full and fragment based config files.
Run ./build-kernel.sh help for more information.
How to modify config files
Complete config files can be modified either with an editor, or preferably
using the kernel Kconfig configuration tools, for example:
$ cp x86_kata_kvm_4.14.x linux-4.14.22/.config
$ pushd linux-4.14.22
$ make menuconfig
$ popd
$ cp linux-4.14.22/.config x86_kata_kvm_4.14.x
Kernel fragments are best constructed using an editor. Tools such as grep and
diff can help find the differences between two config files to be placed
into a fragment.
If adding config entries for a new subsystem or feature, consider making a new fragment with an appropriately descriptive name.
If you want to disable an entire fragment for a specific configuration, you can add the tag # !${arch} or # !confidential in the first line of the fragment. You can also exclude multiple tags on the same line. Note the # at the beginning of the line, this is required to avoid that the tag is interpreted as a configuration.
Example of valid exclusion:
# !s390x !ppc64le
The fragment gathering tool performs some basic sanity checks, and the build-kernel.sh will
fail and report the error in the cases of:
- A duplicate
CONFIGsymbol appearing. - A
CONFIGsymbol being in a fragment, but not appearing in the final .config- which indicates that
CONFIGvariable is not a part of the kernelKconfigsetup, which can indicate a typing mistake in the name of the symbol.
- which indicates that
- A
CONFIGsymbol appearing in the fragments with multiple different values.