Skip to content

[next] Support virtualized TPM attachments to qemu VMS, plus refactor.#346

Merged
chaitu236 merged 11 commits into
ni:nilrt/master/nextfrom
amstewart:feat/next/device-encryption
Jun 16, 2026
Merged

[next] Support virtualized TPM attachments to qemu VMS, plus refactor.#346
chaitu236 merged 11 commits into
ni:nilrt/master/nextfrom
amstewart:feat/next/device-encryption

Conversation

@amstewart

@amstewart amstewart commented Apr 17, 2026

Copy link
Copy Markdown
Contributor

Changes

  1. Fix a warning from QEMU about using an old syntax for marking a QEMU drive as read-only.
  2. Add a new option to the linux start-vm script (-t). When asserted, the script will create, initialize, and attach a virtualized TPM2.0 device to the VM using the swtpm distro package on the host machine.
  3. Refactor the QEMU VM creation process. Instead of using a build.vms.sh bash script, use a Makefile - where the logic is easeier to parse.
    • Also, use the ovmf recipe in OE-core to build the UEFI firmware, instead of using a static copy from somewhere.

AB#3752806

Testing

  • Built VMs with the new Makefile and tested with them manually.

Process

  • Depends on meta-nilrt #977.
  • We should only merge this PR once we have made the changes necessary to consume the new QEMU VM artifact location in ni-central.

Suggested Reviewers:

  • @ni/rtos

@amstewart amstewart requested review from a team and jpautler April 17, 2026 07:40
@amstewart amstewart force-pushed the feat/next/device-encryption branch from c5baa6e to 18ea701 Compare May 28, 2026 20:05
@amstewart

amstewart commented May 28, 2026

Copy link
Copy Markdown
Contributor Author

meta-nilrt 977 has been merged, unblocking this PR.

Patch V2

  • Rebased to latest nilrt/master/next.
  • Rebuilt the core feed package group and images.
  • Validated that the TPM-enabled QEMU artifacts can be made.
usr0@rtosams3:~/projects/nilrt/nilrt/build$ tree -a ../scripts/pipelines/qemu/
../scripts/pipelines/qemu/
├── .gitignore
├── Makefile
├── nilrt-x64-qemu
│   ├── nilrt-x64-qemu.qcow2
│   ├── ni_provisioning.answers
│   ├── OVMF
│   │   ├── ovmf.code.fd
│   │   └── ovmf.vars.fd
│   ├── start-vm.bat
│   ├── start-vm.sh
│   └── tpm
│       ├── .lock
│       └── tpm2-00.permall
├── nilrt-x64-qemu.zip
├── ni_provisioning.answers
├── ni_provisioning.answers.iso
├── start-vm.bat.in
└── start-vm.sh.in

@amstewart amstewart marked this pull request as ready for review May 28, 2026 20:16
@amstewart amstewart requested a review from a team as a code owner May 28, 2026 20:16
@amstewart amstewart requested a review from chaitu236 May 28, 2026 20:16
Comment thread scripts/pipelines/build.vms.sh Outdated
Comment thread docker/build-nilrt.Dockerfile
@amstewart amstewart force-pushed the feat/next/device-encryption branch from 18ea701 to 1a7b4a1 Compare May 29, 2026 18:41
@amstewart

Copy link
Copy Markdown
Contributor Author

Patch v2

  • Fixed commit message.

@amstewart amstewart requested a review from chaitu236 May 29, 2026 18:42
Alex Stewart added 4 commits May 29, 2026 15:26
QEMU throws an error when executing the start script like ...

```
qemu-system-x86_64: -drive if=pflash,format=raw,readonly,file=./OVMF/OVMF_CODE.fd: warning: short-form boolean option 'readonly' deprecated
Please use readonly=on instead
```

Use the new option syntax to satisfy the warning.

Signed-off-by: Alex Stewart <alex.stewart@emerson.com>
Using the swtpm package, linux users can emulate a TPM device - which is
useful when testing Secure Boot and NI Device Encryption workflows
locally.

Add a `-t` option to the QEMU start script that creates and attaches a
software TPM to the VM.

Signed-off-by: Alex Stewart <alex.stewart@emerson.com>
The build.vms.sh pipeline script and associated vm-resources are
somewhat difficult to comprehend and also use a statically built OVMF
UEFI BIOS. In order to support TPM-based secure-boot/measured-boot
testing, we should use the OVMF output from OE. While we're here,
refactor the build.vms tooling to use a Makefile in a directory called
`qemu`, which is hopefully a little easier to maintain.

Signed-off-by: Alex Stewart <alex.stewart@emerson.com>
Docker issues two warnings with the current Dockerfile.

1. Warns that the PYREX_IMAGE arg can have a blank value, resulting in
   an invalid Dockerfile. This is mostly fine, but change to let it use
   `pyrex-oe` as a default, so that docker will stop complaining.
2. Warns that 'FROM' and 'as' on line 2 use different casing. So make
   them both uppercase.

Signed-off-by: Alex Stewart <alex.stewart@emerson.com>
@amstewart amstewart force-pushed the feat/next/device-encryption branch from 1a7b4a1 to 9f02ddf Compare May 29, 2026 19:26
@amstewart

Copy link
Copy Markdown
Contributor Author

Patch v3

  • Rebased to latest nilrt/master/next - since it includes a distro codename upgrade.

@chaitu236 chaitu236 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Everthing else looks fine except removal of build.vms.sh

@amstewart

Copy link
Copy Markdown
Contributor Author

BLOCKED. Block this PR merge until Jeff and I resolve his PR here.

s)
snapshot=true
;;
t)

@jpautler jpautler Jun 12, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we have an explicit check/error if swtpm_setup can't run? Something like this:

t)
    if ! command -v swtpm_setup &>/dev/null; then
        echo "ERROR: -t requires swtpm-tools, but it is not installed or not in PATH" >&2
        exit 1
    fi
    tpm=true
    ;;

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I usually try to avoid doing explicit checks for binaries, unless there are bad consequences for just allowing the later commands in the script to fail. In this case, all that would happen is that the start script would create the ./tpm directory in the VM location and then fail with a "command not found" error. I think that's OK.

Comment thread scripts/pipelines/qemu/Makefile Outdated
ni_provisioning.answers.iso
$(primary_disk_path) : $(vmdeps)
rm -f "$@"
qemu-img create -f qcow2 "$@" "$(DISK_SIZE_MB)""M"

@jpautler jpautler Jun 12, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should qemu-img be wrapped with $(PYREX_RUN) like is done for qemu-system-x86_64? Looks like it used to be wrapped in the previous build.vms.sh.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right; will fix.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed, patch v4.

@jpautler jpautler left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM other than the couple open comments and the separate PR with Makefile changes.

jpautler and others added 7 commits June 16, 2026 11:22
Bitbake cannot handle concurrent invocations against the same build
directory. Without .NOTPARALLEL, running 'make -j' or running make
from our pipelines could trigger multiple simultaneous bitbake calls,
causing lock errors.

Signed-off-by: Jeffrey Pautler <jeffrey.pautler@ni.com>
The '&:' grouped target syntax is only valid for explicit targets in
GNU make, not pattern rules with '%'. Using a pattern rule caused make
to treat ovmf.code.fd and ovmf.vars.fd as independent targets,
resulting in two 'bitbake ovmf' invocations.

Replace the pattern rule with explicit grouped targets.

Signed-off-by: Jeffrey Pautler <jeffrey.pautler@ni.com>
Building nilrt-recovery-media wipes the shared deploy directory as part
of its do_image clean step, deleting ovmf.code.fd and ovmf.vars.fd.
Bitbake's existing stamps still show ovmf as complete, so a plain
'bitbake ovmf' skips do_deploy and leaves the files absent.

Use '-C deploy' to invalidate and rerun do_deploy regardless of stamp
state.

Signed-off-by: Jeffrey Pautler <jeffrey.pautler@ni.com>
The previous KVMOPTS used '$(shell ...)' which runs on the host at
make parse time. When invoked via the pipeline, qemu runs inside a
pyrex container that does not have /dev/kvm mapped, so passing
-enable-kvm unconditionally caused qemu to fail.

Replace KVMOPTS with an inline shell test run through PYREX_RUN so
the check executes in the same container context as qemu itself.

Signed-off-by: Jeffrey Pautler <jeffrey.pautler@ni.com>
Place all intermediate and final build artifacts under bbdir rather
than in the Makefile's working directory. Introduce builddir_tmp for
ephemeral files and builddir_zip_contents for the zip staging area.

Signed-off-by: Jeffrey Pautler <jeffrey.pautler@ni.com>
The nilrt OE build system uses tmp-glibc as its work directory, not tmp.

Signed-off-by: Jeffrey Pautler <jeffrey.pautler@ni.com>
Use the PYREX_RUN wrapper script to ensure that qemu-img commands are
run within the pyrex container, so that we have better control over the
toolchain available.

Signed-off-by: Alex Stewart <alex.stewart@emerson.com>
@amstewart

Copy link
Copy Markdown
Contributor Author

Patch v4

  • Merged jpautler's fixes.
  • Run qemu-img within pyrex.

@chaitu236 chaitu236 merged commit 5053c52 into ni:nilrt/master/next Jun 16, 2026
@amstewart amstewart deleted the feat/next/device-encryption branch June 16, 2026 19:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants