add virtiofs systemd credential handling by dustymabe · Pull Request #4230 · coreos/fedora-coreos-config

dustymabe · 2026-06-23T14:28:29Z

As part of an effort to test more on non-CoreOS bootable
container images we'd like a cross architecture way to
expose systemd credentials into a VM. This commit adds a
new import-virtiofs-systemd-credentials.service that runs
in the initramfs and will copy credentials exposed via the
io.systemd.credentials virtiofs tag into the /run/credentials/@initrd
directory, which will then get imported by systemd itself.

Related to https://github.com/systemd/systemd/issues/29175 upstream.

Assisted-by: <anthropic/claude-opus-4.6>

gemini-code-assist

Code Review

This pull request restructures the build manifests by consolidating package definitions and postprocess scripts into fedora-coreos.yaml and moving shared configurations to shared-el.yaml. It also introduces a new dracut module, 40import-virtiofs-systemd-credentials, to import systemd credentials from a tagged virtiofs share during initramfs. The review feedback highlights critical path mismatches in shared-el.yaml where the new overlay is incorrectly referenced under overlay/ instead of overlay.d/, which would cause build failures. Additionally, a documentation mismatch in the systemd service file was identified regarding the target credentials directory.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

gemini-code-assist · 2026-06-23T14:30:16Z

+# Run in the initramfs so that systemd credentials are in
+# /run/credentials/@system/ before the initramfs-to-real-root transition.


The comment mentions /run/credentials/@system/, but the script import-virtiofs-systemd-credentials.sh actually copies the credentials to /run/credentials/@initrd. Please update the comment to match the actual path used in the script to avoid confusion.

# Run in the initramfs so that systemd credentials are in # /run/credentials/@initrd before the initramfs-to-real-root transition.

dustymabe · 2026-06-23T14:30:35Z

This is built on top of #4227

Please just consider the last commit here.

dustymabe · 2026-06-23T17:27:18Z

Looking at coreos/coreos-assembler#4469 it looks like a desire here is to be able to run tests against other bootable container images (bootc) so adding this functionality maybe should go in https://gitlab.com/fedora/bootc/base-images instead of here.

yasminvalim · 2026-06-23T20:57:28Z

@dustymabe Thanks for working on this! One question I have is: why use virtiofs instead of SMBIOS? Is there a specific reason to choose virtiofs? I'd just like to understand better and get a bit more context.

dustymabe · 2026-06-23T21:06:21Z

@dustymabe Thanks for working on this! One question I have is: why use virtiofs instead of SMBIOS? Is there a specific reason to choose virtiofs? I'd just like to understand better and get a bit more context.

Good question. Basically systemd/systemd#29175 (comment)

We need something that will work across every architecture we want to run tests on if at all possible.

yasminvalim · 2026-06-24T14:03:28Z

Got it, makes sense! Thank you for explain! I will make changes in my PR to see if is possible to support virtiofs instead of SMBIOS so we can be in the same page :)

dustymabe · 2026-06-24T14:13:15Z

Got it, makes sense! Thank you for explain! I will make changes in my PR to see if is possible to support virtiofs instead of SMBIOS so we can be in the same page :)

Not quite ready to push this up yet but you can see the COSA side changes in the mantle/platform: add virtiofs systemd credential passing commit on this branch: https://github.com/dustymabe/coreos-assembler/commits/dusty-running/

dustymabe · 2026-06-24T14:15:42Z

@travier interested in your thoughts on this from a security perspective.. and also the question of:

so adding this functionality maybe should go in https://gitlab.com/fedora/bootc/base-images instead of here.

If we don't put it in bootc then we could add a ConditionKernelCommandLine=ignition.firstboot to limit the credential injection only to the first boot of the machine.

dustymabe · 2026-06-25T03:40:37Z

Pushed a second commit here to fix the problem mentioned in #4227 (comment)

build-rootfs: sort overlay dirs to allow overriding

travier · 2026-06-26T10:58:00Z

Pushed a second commit here to fix the problem mentioned in #4227 (comment)
build-rootfs: sort overlay dirs to allow overriding

This feels unrelated to this PR. Let's split into another one so that we can get it in directly?

dustymabe · 2026-06-26T13:07:39Z

Pushed a second commit here to fix the problem mentioned in #4227 (comment)
build-rootfs: sort overlay dirs to allow overriding
This feels unrelated to this PR. Let's split into another one so that we can get it in directly?

#4236

travier · 2026-06-26T13:52:36Z

Let's drop the second commit from this one.

This looks very interesting but I need to think about it a bit more and wrap my head around it. It's interesting that there is discussion upstream and it feels like something reasonable that we could tweak once upstream approves it.

Also related: https://systemd.io/VM_INTERFACE/

dustymabe · 2026-06-26T15:45:04Z

Let's drop the second commit from this one.

Done.

rebased this PR. on top of latest testing-devel.

This looks very interesting but I need to think about it a bit more and wrap my head around it.

👍

Also related: https://systemd.io/VM_INTERFACE/

Is there anything there that would cause us to change this?

travier · 2026-06-26T16:05:54Z

Small note, the @initrd gets interpreted in your commit message by GitHub so the poor user with that name will get a notification every time this commit is pushed.

travier · 2026-06-26T16:10:25Z

So if I understand correctly, this is only for the QEMU virtualization case as this requires virtiofs. But in this case, shouldn't we use the existing smbios-type-11 support in systemd as that would work as well and should work in limit virtualization context that we have here?

travier · 2026-06-26T16:12:44Z

Also related: systemd.io/VM_INTERFACE
Is there anything there that would cause us to change this?

Not directly in this PR but we could consider using AF_VSOCK for the connection to the system in the QEMU case (which I think is the idea here?) as that would remove the need for networking to be up. Most likely for later but that came to mind while reading this one.

dustymabe · 2026-06-26T16:45:35Z

So if I understand correctly, this is only for the QEMU virtualization case as this requires virtiofs. But in this case, shouldn't we use the existing smbios-type-11 support in systemd as that would work as well and should work in limit virtualization context that we have here?

I'm looking for something cross architecture. smbios doesn't work everywhere we need it to (kernel args would, but I think cracking open images to inject kernel args for every test would negate some of the test) and maintaining different solutions for different architectures is fraught with problems IMO.

dustymabe · 2026-06-26T16:50:25Z

Not directly in this PR but we could consider using AF_VSOCK for the connection to the system in the QEMU case (which I think is the idea here?) as that would remove the need for networking to be up. Most likely for later but that came to mind while reading this one.

I actually have AF_SOCK working (among some of the commits in https://github.com/dustymabe/coreos-assembler/commits/dusty-running/), but I haven't opened a PR for it yet.

Part of the problem there is coreos/fedora-coreos-tracker#2098 (comment)

Basically I was relying on a Ignition provided SSH key, but using VSOCK to connect, but that doesn't work.

But in general, there are two problems:

connecting to the machine through a back channel (vsock)
getting a credential onto a machine through !ignition

The implementation for them is independent (one doesn't depend on the other).

travier · 2026-06-26T18:57:47Z

So if I understand correctly, this is only for the QEMU virtualization case as this requires virtiofs. But in this case, shouldn't we use the existing smbios-type-11 support in systemd as that would work as well and should work in limit virtualization context that we have here?

I'm looking for something cross architecture. smbios doesn't work everywhere we need it to (kernel args would, but I think cracking open images to inject kernel args for every test would negate some of the test) and maintaining different solutions for different architectures is fraught with problems IMO.

Ah yes indeed. I remembered that this was not supported on all architectures (thus why this can not replace Ignition) but I thought maybe QEMU could still do it. Apparently that's unlikely and it's only documented under the i686 target: https://www.qemu.org/docs/master/system/invocation.html#hxtool-4

Also from https://www.dmtf.org/standards/smbios:

Originally designed for Intel® processor architecture systems, SMBIOS now includes support for IA-32 (x86), x64 (x86-64, Intel64, AMD64, EM64T), Intel® Itanium® architecture, 32-bit ARM (Aarch32) and 64-bit ARM (Aarch64).

travier · 2026-06-26T19:01:44Z

So overall this looks good, but this now becomes another access point that we would have to measure for confidential computing. So if that works for you, I would prefer we either restrict that to testing releases/builds (likely not ideal) or we add a condition to disable it when booted from a measured UKI (systemd has this option now).

dustymabe · 2026-06-26T19:24:33Z

So overall this looks good, but this now becomes another access point that we would have to measure for confidential computing.

hmm. how does systemd handle this today for say smbios based credential injection? Do they measure that?

So if that works for you,

I really only care about testing and not trying to enable this generically for users.

I would prefer we either restrict that to testing releases/builds (likely not ideal) or we add a condition to disable it when booted from a measured UKI (systemd has this option now).

Yeah not sure how we would do the "restrict to testing releases/builds" if we also wanted to use this to test our production builds.

I'm happy to add a Condition if you give me the string I'll add it to the unit file.

Also, this question still remains:

Looking at coreos/coreos-assembler#4469 it looks like a desire here is to be able to run tests against other bootable container images (bootc) so adding this functionality maybe should go in https://gitlab.com/fedora/bootc/base-images instead of here.

If we keep it here in CoreOS we can do a ConditionKernelCommandLine=ignition.firstboot to further limit potential problems, but having it in bootc starts to open us up to being able to run our kola tests against bootc images.

travier · 2026-06-26T19:29:51Z

So overall this looks good, but this now becomes another access point that we would have to measure for confidential computing.

hmm. how does systemd handle this today for say smbios based credential injection? Do they measure that?

Yes, they started measuring SMBIOS Type 11 entries read from system-stub into a PCR (12 I think).

So if that works for you,

I really only care about testing and not trying to enable this generically for users.

👍🏻 but once it's in, someone will use it 🙂.

I would prefer we either restrict that to testing releases/builds (likely not ideal) or we add a condition to disable it when booted from a measured UKI (systemd has this option now).

Yeah not sure how we would do the "restrict to testing releases/builds" if we also wanted to use this to test our production builds.

I'm happy to add a Condition if you give me the string I'll add it to the unit file.

Will do.

Also, this question still remains:

Looking at coreos/coreos-assembler#4469 it looks like a desire here is to be able to run tests against other bootable container images (bootc) so adding this functionality maybe should go in gitlab.com/fedora/bootc/base-images instead of here.

If we keep it here in CoreOS we can do a ConditionKernelCommandLine=ignition.firstboot to further limit potential problems, but having it in bootc starts to open us up to being able to run our kola tests against bootc images.

Agree that it would be best to have that in the bootc base image for wider testing. Or we could use that for FCOS testing on PRs to the bootc repo / pipeline.

travier · 2026-06-26T19:32:34Z

From https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html#ConditionSecurity=:

ConditionSecurity=!cvm
ConditionSecurity=!measured-uki
ConditionSecurity=!measured-os

@initrd

As part of an effort to test more on non-CoreOS bootable container images we'd like a cross architecture way to expose systemd credentials into a VM. This commit adds a new import-virtiofs-systemd-credentials.service that runs in the initramfs and will copy credentials exposed via the io.systemd.credentials virtiofs tag into the /run/credentials/@initrd directory, which will then get imported by systemd itself. Related to systemd/systemd#29175 upstream. Assisted-by: <anthropic/claude-opus-4.6>

dustymabe · 2026-06-26T20:20:48Z

From https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html#ConditionSecurity=:

added

Agree that it would be best to have that in the bootc base image for wider testing. Or we could use that for FCOS testing on PRs to the bootc repo / pipeline.

Do you think I should open this against bootc then? Or maybe we do it in parallel and don't block on it being there just in case?

I updated this PR to have ConditionKernelCommandLine=ignition.firstboot

travier · 2026-06-26T22:48:26Z

I think we can do it in parallel and we can start testing this here.

dustymabe · 2026-07-01T17:33:07Z

@travier anything blocking this at this point?

travier · 2026-07-02T10:51:53Z

+# Clean up the mount
+umount "${MOUNTPOINT}"


We should be able to skip that by using a dedicated mount namespace like we do in other units that mount filesystems. https://github.com/coreos/bootupd/blob/main/systemd/bootloader-update.service#L16

travier · 2026-07-02T10:52:54Z

+
+# Clean up the mount
+umount "${MOUNTPOINT}"
+rmdir "${MOUNTPOINT}" 2>/dev/null || true


Ah, maybe not if we need to cleanup the mountpoint

travier · 2026-07-02T10:55:26Z

+}
+
+installkernel() {
+    instmods -c virtiofs


This will make our initrd 35K (xz compressed) bigger so should be fine.

travier

One potential nit but could be a followup if actually possible.
LGTM

gemini-code-assist Bot reviewed Jun 23, 2026

View reviewed changes

dustymabe force-pushed the dusty-virtifs-systemd-credential branch from a3b0a03 to 914cc8b Compare June 23, 2026 14:37

dustymabe force-pushed the dusty-virtifs-systemd-credential branch 2 times, most recently from c594a82 to 15c2f2b Compare June 24, 2026 02:31

dustymabe force-pushed the dusty-virtifs-systemd-credential branch from 15c2f2b to bb2d251 Compare June 25, 2026 03:39

dustymabe marked this pull request as ready for review June 25, 2026 03:39

This was referenced Jun 25, 2026

rework manifests/overlays #4227

Merged

NO-JIRA: manifests: drop redundant definitions with fedora-coreos-config coreos/rhel-coreos-config#276

Merged

dustymabe force-pushed the dusty-virtifs-systemd-credential branch from bb2d251 to 9a9a6a5 Compare June 26, 2026 15:42

dustymabe force-pushed the dusty-virtifs-systemd-credential branch from 9a9a6a5 to 76f82eb Compare June 26, 2026 20:20

dustymabe enabled auto-merge (rebase) July 1, 2026 17:33

travier reviewed Jul 2, 2026

View reviewed changes

travier approved these changes Jul 2, 2026

View reviewed changes

dustymabe merged commit a40d2b8 into coreos:testing-devel Jul 2, 2026
7 checks passed

dustymabe deleted the dusty-virtifs-systemd-credential branch July 2, 2026 10:56

		# Run in the initramfs so that systemd credentials are in
		# /run/credentials/@system/ before the initramfs-to-real-root transition.

Uh oh!

Conversation

dustymabe commented Jun 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

gemini-code-assist Bot Jun 23, 2026

Choose a reason for hiding this comment

Uh oh!

dustymabe commented Jun 23, 2026

Uh oh!

dustymabe commented Jun 23, 2026

Uh oh!

yasminvalim commented Jun 23, 2026

Uh oh!

dustymabe commented Jun 23, 2026

Uh oh!

yasminvalim commented Jun 24, 2026

Uh oh!

dustymabe commented Jun 24, 2026

Uh oh!

dustymabe commented Jun 24, 2026

Uh oh!

dustymabe commented Jun 25, 2026

Uh oh!

travier commented Jun 26, 2026

Uh oh!

dustymabe commented Jun 26, 2026

Uh oh!

travier commented Jun 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dustymabe commented Jun 26, 2026

Uh oh!

travier commented Jun 26, 2026

Uh oh!

travier commented Jun 26, 2026

Uh oh!

travier commented Jun 26, 2026

Uh oh!

dustymabe commented Jun 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dustymabe commented Jun 26, 2026

Uh oh!

travier commented Jun 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

travier commented Jun 26, 2026

Uh oh!

dustymabe commented Jun 26, 2026

Uh oh!

travier commented Jun 26, 2026

Uh oh!

travier commented Jun 26, 2026

Uh oh!

dustymabe commented Jun 26, 2026

Uh oh!

travier commented Jun 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dustymabe commented Jul 1, 2026

Uh oh!

travier Jul 2, 2026

Choose a reason for hiding this comment

Uh oh!

travier Jul 2, 2026

Choose a reason for hiding this comment

Uh oh!

travier Jul 2, 2026

Choose a reason for hiding this comment

Uh oh!

travier left a comment

Choose a reason for hiding this comment

Uh oh!

dustymabe commented Jun 23, 2026 •

edited

Loading

travier commented Jun 26, 2026 •

edited

Loading

dustymabe commented Jun 26, 2026 •

edited

Loading

travier commented Jun 26, 2026 •

edited

Loading

travier commented Jun 26, 2026 •

edited

Loading