confidential guest kernel hardening changes #11257

mythi · 2025-05-09T15:01:16Z

Drop some fragments from the confidential guest kernel builds. The PR should result in the following .config diff:

-CONFIG_HW_RANDOM=y
-# CONFIG_HW_RANDOM_TIMERIOMEM is not set
-# CONFIG_HW_RANDOM_INTEL is not set
-# CONFIG_HW_RANDOM_AMD is not set
-# CONFIG_HW_RANDOM_BA431 is not set
-# CONFIG_HW_RANDOM_VIA is not set
-CONFIG_HW_RANDOM_VIRTIO=y
-# CONFIG_HW_RANDOM_CCTRNG is not set
-# CONFIG_HW_RANDOM_XIPHERA is not set
+# CONFIG_HW_RANDOM is not set
 # CONFIG_APPLICOM is not set
 # CONFIG_MWAVE is not set
 # CONFIG_DEVMEM is not set
@@ -2359,8 +2351,7 @@
 CONFIG_VIRTIO_BALLOON=y
 CONFIG_VIRTIO_MEM=y
 # CONFIG_VIRTIO_INPUT is not set
-CONFIG_VIRTIO_MMIO=y
-CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y
+# CONFIG_VIRTIO_MMIO is not set

Tested on a Kata TDX guest and it boots OK.

build-kernel.sh supports exluding fragments from the common base set based on the kernel target architecture. However, there are also cases where the base set must be stripped down for other reason. For example, confidential guest builds want to exclude some drivers the untrusted host may try to add devices (e.g., virtio-rng). Make build-kernel.sh to skip fragments tagged using '!confidential' when confidential guest kernels are built. Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>

As the comment in the fragment suggests, this is for the firecracker builds and not relevant for confidential guests, for example. Exlude mmio.conf fragment by adding the new !confidential tag to drop virtio MMIO transport for the confidential guest kernel (as virtio PCI is enough for the use cases today). Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>

Linux CoCo x86 guest is hardened to ensure RDRAND provides enough entropy to initialize Linux RNG. A failure will panic the guest. For confidential guests any other RNG source is untrusted so disable them. Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>

6.12.28 has been released, let's bump to it. Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>

Adding: "-object rng-random,id=rng0,filename=/dev/urandom -device virtio-rng-pci,rng=rng0" for confidential guests is not necessary as the RNG source cannot be trusted and the guest kernel has the driver already disable as well. Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>

mythi · 2025-05-12T14:16:05Z

added v6.12.28 LTS bump.

stevenhorsman · 2025-05-14T10:19:10Z

tools/packaging/kernel/configs/fragments/common/virtio-extras.conf

@@ -0,0 +1,4 @@
+# !confidential
+# This is used by the s390 arch at least. Leave it on globally.


@BbolroC will this impact the SE kernel?

I am not sure about the impact, but I will run our nightly SE test against this PR and share if all tests are passed. Thanks for the notice.

Maybe I should bring this to @hbrueckner. What do you think about this?

See ab29c8c also. According to that, these configs are not used by the runtime on s390 (which looks a conflict with the comment in this file?).

Ah, right. I have also got the following feedback from inside:

The IBM Z and LinuxOne has an on-chip true random generator.

But just to make sure it, I will trigger the nightly test and share the result today. Thanks!

I believe that is expected and OK for s390x given:

tools/packaging/kernel/configs/fragments/s390/base.conf:CONFIG_HW_RANDOM_S390=y

yeah, interestingly, I still got CONFIG_HW_RANDOM=y after commenting out CONFIG_HW_RANDOM_S390

It seems CONFIG_ZCRYPT=y depends on CONFIG_HW_RANDOM=y. Is it okay for you the kernel is hardened enough for the platform even if CONFIG_HW_RANDOM=y which seems you don't want to have for x86_64?

I got an internal confirmation like CCA mode for our crypto card depends on the HW random number generator. The mode is not used in IBM SEL. So I think the resulted configs are okay for the platform. Let met finish the test.

Is it okay for you the kernel is hardened enough for the platform even if CONFIG_HW_RANDOM=y which seems you don't want to have for x86_64?

It does not get enabled on x86_64 (see the PR cover letter) so we should be good. (thanks a lot for the help btw!)

BbolroC · 2025-05-14T10:40:56Z

@mythi Could you explain why you try to drop those configs for CoCo? Just out of curiosity. 😉

I've checked the reason from the commit message:

Linux CoCo x86 guest is hardened to ensure RDRAND provides enough
entropy to initialize Linux RNG. A failure will panic the guest.

For confidential guests any other RNG source is untrusted so disable
them.

Let me rephrase my question. Could you elaborate more on For confidential guests any other RNG source is untrusted?

mythi · 2025-05-14T11:46:13Z

@mythi Could you explain why you try to drop those configs for CoCo? Just out of curiosity. 😉

I've checked the reason from the commit message:

Linux CoCo x86 guest is hardened to ensure RDRAND provides enough
entropy to initialize Linux RNG. A failure will panic the guest.

For confidential guests any other RNG source is untrusted so disable
them.

Let me rephrase my question. Could you elaborate more on For confidential guests any other RNG source is untrusted?

I guess it would be better to say 'host provided RNG source is not trusted' which then answers your question.

BbolroC · 2025-05-14T11:53:02Z

I guess it would be better to say 'host provided RNG source is not trusted' which then answers your question.

yep, it makes sense to me. thanks!

BbolroC · 2025-05-14T15:11:11Z

@mythi @stevenhorsman all nightly tests with the PR have been passed. Also, it was confirmed that no issues are expected for the current crypto use cases for IBM SEL. Thanks!

BbolroC

LGTM, thanks @mythi !

stevenhorsman

The CI is passing, so I guess this is okay to be merged. Does it need to get into 3.17.0, or can it wait until after the release?

mythi · 2025-05-16T04:43:07Z

The CI is passing, so I guess this is okay to be merged. Does it need to get into 3.17.0, or can it wait until after the release?

My goal was to have it in the release.

A change in the qemu command line is suspected to have caused this change in ACPI table measurement, the following flags were removed: -object rng-random,id=rng0,filename=/dev/urandom -device virtio-rng-pci,rng=rng0 In PR kata-containers/kata-containers#11257 Signed-off-by: Paul Meyer <katexochen0@gmail.com>

mythi added 2 commits May 9, 2025 17:53

katacontainersbot added the size/small Small and simple task label May 9, 2025

mythi added 3 commits May 12, 2025 17:12

versions: bump LTS kernel

a44dfb8

6.12.28 has been released, let's bump to it. Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>

mythi force-pushed the coco-guest-hardening branch from 49eca2c to ab29c8c Compare May 12, 2025 14:15

stevenhorsman reviewed May 14, 2025

View reviewed changes

BbolroC approved these changes May 14, 2025

View reviewed changes

stevenhorsman added the ok-to-test label May 14, 2025

stevenhorsman approved these changes May 15, 2025

View reviewed changes

fidencio merged commit 219d6e8 into kata-containers:main May 16, 2025
520 of 538 checks passed

mythi mentioned this pull request May 16, 2025

Hardening the Host Guest Interface confidential-containers/confidential-containers#297

Open

7 tasks

		@@ -0,0 +1,4 @@
		# !confidential
		# This is used by the s390 arch at least. Leave it on globally.

confidential guest kernel hardening changes #11257

confidential guest kernel hardening changes #11257

Uh oh!

Conversation

mythi commented May 9, 2025

Uh oh!

mythi commented May 12, 2025

Uh oh!

stevenhorsman May 14, 2025

Choose a reason for hiding this comment

Uh oh!

BbolroC May 14, 2025

Choose a reason for hiding this comment

Uh oh!

BbolroC May 14, 2025

Choose a reason for hiding this comment

Uh oh!

mythi May 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BbolroC May 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mythi May 14, 2025

Choose a reason for hiding this comment

Uh oh!

BbolroC May 14, 2025

Choose a reason for hiding this comment

Uh oh!

BbolroC May 14, 2025

Choose a reason for hiding this comment

Uh oh!

BbolroC May 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mythi May 14, 2025

Choose a reason for hiding this comment

Uh oh!

BbolroC commented May 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mythi commented May 14, 2025

Uh oh!

BbolroC commented May 14, 2025

Uh oh!

BbolroC commented May 14, 2025

Uh oh!

BbolroC left a comment

Choose a reason for hiding this comment

Uh oh!

stevenhorsman left a comment

Choose a reason for hiding this comment

Uh oh!

mythi commented May 16, 2025

Uh oh!

Uh oh!

Uh oh!

mythi May 14, 2025 •

edited

Loading

BbolroC May 14, 2025 •

edited

Loading

BbolroC May 14, 2025 •

edited

Loading

BbolroC commented May 14, 2025 •

edited

Loading