<dustymabe>
bgilbert: so if I take my Compaq server (hypothetical example with unlikely hardware vendor) that has been running f32 with secure boot enabled for years now, unless I do something to the hardware (like run a vendor firmware update), my system will continue to boot?
<bgilbert>
dustymabe: right, the OS is responsible for updating the denylist
<bgilbert>
it feels like a bit of a time-bomb though
<dustymabe>
bgilbert: so what is it in qemu that's making older systems (pre-baked from years ago) not boot?
guesswhat6 has joined #fedora-coreos
<bgilbert>
dustymabe: I'm still digging, but presumably it ships with a newer denylist
<bgilbert>
as will new hardware
<bgilbert>
re the "dangling thread" ^: I don't think we ever followed through
<dustymabe>
bgilbert: yeah, i wouldn't be surprised
<bgilbert>
okay, looks like dbxtool is the low-level update tool, but it's wrapped by fwupd, which knows to refuse to update dbx if the ESP contains binaries with denied signatures
<bgilbert>
(assuming nothing about the FCOS ESP handling confuses it; I haven't tested)
<bgilbert>
dustymabe: I just spot-checked `dbxtool -l` inside `cosa run --qemu-firmware uefi-secure` and found hashes from the April 2021 dbx update
<bgilbert>
I'd guess that OVMF builds eventually incorporate newer dbx
<bgilbert>
hmm. `fwdupdtool get-updates` in that VM says `cannot find default ESP: No ESP or BDP found`
<dustymabe>
yeah. I think the thing that confuses me is the relationship between the different pieces
<dustymabe>
i.e is the controlling mechanism inside the image that's baked OR is it in the hardware/firmware of the machine
<dustymabe>
the sense that I'm getting is that it's a combination of both
<bgilbert>
the dbx denylist is baked into the firmware and then updated similar to a firmware update
<bgilbert>
OSes are supposed to apply those updates to prevent the machine from later being compromised by a known vuln
<dustymabe>
ok it makes sense now
<dustymabe>
so.. if a person never updates their own firware, they'll continue to be able to boot
<bgilbert>
yes, though somewhat defeating the secure in Secure Boot
<dustymabe>
but if they do update their firmware or take the disk and move it to a different machine, then boot could be denied
<bgilbert>
right
<dustymabe>
well at least I understand it a bit more now :)
<bgilbert>
I think we should probably try booting an old FCOS with old UEFI firmware (in qemu), upgrade to current, and then see whether fwupd correctly prevents a dbx update
fifofonix has quit [Read error: Connection reset by peer]
<dustymabe>
:) - care to take that one?
<bgilbert>
the concern is that it won't find our ESP (not mounted by default) and then decide to update dbx without checking the existing bootloader
<dustymabe>
or maybe open an issue for it?
<bgilbert>
(or read the code, I suppose)
<dustymabe>
yep. that's a worrying concern
<dustymabe>
just when you think everything is all stable and nice.. dusty has to go writing tests
<bgilbert>
yeah, no more writing tests, all they do is find problems
<bgilbert>
I'll open an issue. it might be a good task for someone to get some experience in the space
<bgilbert>
actually
<bgilbert>
dustymabe: could you open a bug with the test results you saw, and I'll comment on it?
<dustymabe>
yep.
<bgilbert>
ty
<jlebon>
do i understand correctly the concern here is that FCOS isn't "fulfilling its job" of updating the firmware?
<jlebon>
presumably as sole owner of the system
<jlebon>
and so users' systems are still running with out of date revocation lists?
<bgilbert>
that's one concern. it undermines Secure Boot protections
<bgilbert>
another concern is that we need to verify that a user deciding to update their firmware with fwupd won't brick their FCOS install
<jlebon>
ack gotcha
<jlebon>
one the output of this should probably be an entry in the docs for now at least showing how to use fwupd
<millerthegorilla>
Hi, in my butane/ignition I have a user with a supplementary group membership of the video group. Boot fails with journalctl message with failed to configure user - useradd: group 'video' does not exist. But the group 'video' is definitely in /etc/group (cat /etc/group in emergency mode), and if I try and create the group using the ignition
<millerthegorilla>
file, boot fails complaining that the 'video' group already exists. I am using ansible so I can add the user to the group later on, but I am a bit confused as to why this would happen.
<jlebon>
bgilbert: would you be against ignition learning to promote a group from /usr/lib to /etc ? compile-knob conditionalized probably
<bgilbert>
I see this as a shadow-utils bug, but it's so painful that yeah, it probably deserves a workaround
<bgilbert>
s/adduser/useradd/
<bgilbert>
my Debian roots are showing
<jlebon>
i can file an ignition and we can discuss there
<millerthegorilla>
bgilbert thanks. I have been having all sorts of fun recently with the various group files, getent, lib/group, sssd and other forms of weird misdirection.
<bgilbert>
jlebon: +1
<bgilbert>
millerthegorilla: yeah, it's not intuitive
<uny[m]>
Is there a way to have the CoreOS ISO boot to the system it just installed?
<uny[m]>
It takes a support request to my ISP to mount/unmount an ISO, so I'd like to try the new system without unmounting the ISO first.
<uny[m]>
Was hoping for a boot selector ... or to be able to chainload to /dev/vda from the boot command line ... but I'm not seeing how to do it.
<uny[m]>
Right, it won't grow until I can figure out how to boot /dev/vda.
gursewak has quit [Remote host closed the connection]
<bgilbert>
uny[m]: the root partition is expanded on first boot, yes. it's after Ignition runs, and doesn't happen if you've used the Ignition config to customize your storage.
<uny[m]>
thanks, so far so good.
<bgilbert>
uny[m]: the ISO doesn't have a built-in way to launch the installed system directly. kexec exists, but there are no purpose-built tools to use it for that purpose
<bgilbert>
oh, maybe you're asking for a "boot to HD" entry in the boot menu
<uny[m]>
I didn't see how to kexec to /dev/vda ... is it easy? Some web searching made it look pretty hard.
<bgilbert>
haven't done it, but I don't think it's especially easy
<uny[m]>
Yes, "Boot to HD" would have been awesome!
<bgilbert>
I've seen ISOs with a "boot to HD" entry before. might be reasonable to add
<uny[m]>
So I had support unmount the ISO (they responded quick!) and I've booted into my new system ... and I notice I didn't give any users passwords and didn't assign the root user an ssh key in my .ign.
<uny[m]>
Just went with the default example.bu in the docs.
<uny[m]>
How do I get root permission?
<bgilbert>
did you assign the core user an SSH key?
<uny[m]>
AH, I didn't realize core was magic.
<bgilbert>
it has sudo access by default
<uny[m]>
I gave bronson an SSH key, but I don't seem to have sudo access.
<uny[m]>
Crud.
<bgilbert>
do you have console access?
<uny[m]>
Well, I guess I need to reinstall with a core user?
<millerthegorilla>
I included remote files in the config.ign but when I boot I am getting a tcp lookup error. Shouldn't networking be finished and working by the time these files are downloaded? I tried setting timeouts under ignition, of http_total 120, but the http requests didn't timeout, and so I am unable to see the log - is it written to disk at a path I
<millerthegorilla>
can locate?
<bgilbert>
millerthegorilla: does it drop to an emergency shell prompt, or wait forever?
<millerthegorilla>
waits forever. So, I tried to set the timeouts and do it again, but it still tries forever (no timelimit)
<bgilbert>
hmm. what platform?
<bgilbert>
Ignition doesn't wait for networking to come up, which is why it retries forever
<millerthegorilla>
its a rpi4b
<bgilbert>
"networking up" is hard to define, so Ignition just assumes it can wait long enough
<bgilbert>
DHCP?
<bgilbert>
wired Ethernet?
<millerthegorilla>
So, if I just leave it? DHCP should be automatic. If I boot the pi as coreos it is assigned an ip, eventually. Its not quick. but it gets there.
<bgilbert>
I mean, if it's 30 seconds that seems fine, but if it's multiple minutes, something is wrong
<millerthegorilla>
its longer than that, I think, but I will check. The http request isn't blocking then, and so the networking should come up in the background? I will try it again.
<bgilbert>
correct, NetworkManager runs in parallel
<uny[m]>
grub worked, thanks bgilbert and jlebon I can access the core user now.
<bgilbert>
uny[m]: 🎉
<jlebon>
nice! :)
<uny[m]>
And /sysroot is expanded as expected. Time to get to work.
<millerthegorilla>
looks like it worked. Just a missing overwrite and it should boot, thanks!
<bgilbert>
millerthegorilla: 🎉
<millerthegorilla>
fri night celebrations to all!
millerthegorilla has quit [Quit: millerthegorilla]