Skip to content

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

Open
amstewart wants to merge 4 commits into
ni:nilrt/master/nextfrom
amstewart:feat/next/device-encryption
Open

[next] Support virtualized TPM attachments to qemu VMS, plus refactor.#346
amstewart wants to merge 4 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
    ;;

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.

@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.

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