Run integration using uroot

[jimmykarily]

This makes it possible to run the tests both locally and in CI with: make integration (at least when the host is based on Arch linux because it still relies on /usr/share/edk2-ovmf/x64/OVMF_VARS.fd and /usr/share/edk2-ovmf/x64/OVMF_CODE.secboot.fd to be around. But we can fix that later by either running the tests in a container locally or by adding these 2 files in git (TBD).

Note: One test is still failing but I'm trying to understand how the original one worked in order to fix it.

[jimmykarily]

Currently having trouble getting KVM to work on github runners (with container: archlinux:latest possibly complicating things)

[jimmykarily]

Currently having trouble getting KVM to work on github runners (with container: archlinux:latest possibly complicating things)

ok KVM problem finally solved (#4a71d2c). Now tests fail the same way locally and in CI.

The test that fails is this one: https://github.com/Foxboron/sbctl/pull/302/files#diff-ce25e955d527dcf8278d30d19452c97b5ff2b62824e2b60c02e0a90ba88e4596R20

and it expects the machine to be booted in secure boot mode. For this to work, we need to have the efirvars populated (at least PK enrolled). I don't fully understand how vmtest works yet but although we start with empty vars, I see this test succeeds which means something enrolled keys. Is it because of the order of tests here?

In any case, for secure boot to be enabled, we would need to reboot the VM. I'm not sure if that's possible with vmtest. @Foxboron maybe you can chime in at this point since you've used these libraries in go-uefi too. In the meantime I'll keep trying things.

[jimmykarily]

Currently having trouble getting KVM to work on github runners (with container: archlinux:latest possibly complicating things)

ok KVM problem finally solved (#4a71d2c). Now tests fail the same way locally and in CI.

The test that fails is this one: https://github.com/Foxboron/sbctl/pull/302/files#diff-ce25e955d527dcf8278d30d19452c97b5ff2b62824e2b60c02e0a90ba88e4596R20

and it expects the machine to be booted in secure boot mode. For this to work, we need to have the efirvars populated (at least PK enrolled). I don't fully understand how vmtest works yet but although we start with empty vars, I see this test succeeds which means something enrolled keys. Is it because of the order of tests here?

In any case, for secure boot to be enabled, we would need to reboot the VM. I'm not sure if that's possible with vmtest. @Foxboron maybe you can chime in at this point since you've used these libraries in go-uefi too. In the meantime I'll keep trying things.

It was the order of things. I just made sure the test re-uses the same vars from the previous test (the one that enrolled the keys) and it now works.

[Foxboron]

and it expects the machine to be booted in secure boot mode. For this to work, we need to have the efirvars populated (at least PK enrolled). I don't fully understand how vmtest works yet but although we start with empty vars, I see this test succeeds which means something enrolled keys. Is it because of the order of tests here?

The abstractions I wound up with in go-uefi isn't necessarily great. WithVM() is suppose to ensure we are using the same OVMF variables between each of the tests, and each t.Run() inside the test boots each of their own VM to ensure we have a clean slate.

[jimmykarily]

I think it's fine for now. Small steps towards perfection :).

Also, I think the whole tests/utils directory can now be deleted, no? Maybe the make_image.sh and the /tests/kernel dir too?

[Foxboron]

Also, I think the whole tests/utils directory can now be deleted, no? Maybe the make_image.sh and the /tests/kernel dir too?

I think so yes, there shouldn't be anything important there now.

[Foxboron]

Cool, thanks for working on this.

It would be nice to squash together some of these commits into logical ones :)

I'll also try and fix the "deploy" thing on github so it doesn't spam the PRs.

[jimmykarily]

Commits squashed to just 2

[kerneis-anssi]

@Foxboron This PR broke my build, I think you need to run go mod tidy.

[jimmykarily]

Strange, go mod tidy indeed makes some changes but otoh the building pipeline didn't fail:

https://github.com/Foxboron/sbctl/actions/runs/8829203645/job/24239720668

Building locally also doesn't fail. Sometimes I don't understand go :D .

[kerneis-anssi]

I also don't understand go :-D My build broke only because I did peculiar things, to be honest (I run go mod vendor before building offline, and it's the former step that fails).

[Foxboron]

Mm, I'll push a fix and maybe try and do a release soon'ish.