Re: [systemd-devel] Fedora 38 and signed PCR binding
On Sa, 02.09.23 22:22, Aleksandar Kostadinov (akost...@redhat.com) wrote: > Looking at the PR [1] it looks like I need to do a lot of things at > each update manually. Is the thing in the comment the only thing I > need to do or are there other things as well? There's nowadays "ukify" that does all of this for you in one relatively easy step, it's our recommended approach to building UKIs these days. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Fedora 38 and signed PCR binding
On Sa, 02.09.23 22:18, Aleksandar Kostadinov (akost...@redhat.com) wrote: > Hello, > > Trying to configure Signed PCR binding on Fedora 38 by following > article [1] and adapting commands for signing. > > What I did was basically this: > > openssl genrsa -out /etc/systemd/tpm2-pcr-private-key.pem 2048 > > openssl rsa -in /etc/systemd/tpm2-pcr-private-key.pem -pubout -out > > /etc/systemd/tpm2-pcr-public-key.pem > > sudo systemd-cryptenroll --tpm2-device=auto > > --tpm2-public-key-pcrs=7+9+11+12+13+14+15 /dev/sda3 > > added tpm2-device=auto,tpm2-pcrs=7+9+11+12+13+14+15 > > But automatic unlocking does *not* work. And This is what > systemd-measure returns: > > $ /usr/lib/systemd/systemd-measure status > Warning: current kernel image does not support measuring itself, the > command line or initrd system extension images. > The PCR measurements seen are unlikely to be valid. > # PCR[11] Unified Kernel Image (NOT SET!) > 11:sha1= > 11:sha256= > # PCR[12] Kernel Parameters (NOT SET!) > 12:sha1= > 12:sha256= > # PCR[13] initrd System Extensions (NOT SET!) > 13:sha1= > 13:sha256= > > Did I do something wrong? Is just necessary integration missing from > Fedora 38 so I better revert to normal PCR binding? Is your kernel built with sd-stub glued in fron of it? i.e. did you use ukify? Note that fedora still uses a legacy boot path with grub and traditional kernels, instead of sd-boot/sd-stub and UKIs. PCR measurements are messy there, and the pcr signature stuff as implemented in systemd-measure doesn't work there. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Online backup API for systemd-journal?
On Mo, 04.09.23 16:35, Etienne Doms (etienne.d...@gmail.com) wrote: > Hi, > > I have some embedded systems in the wild, not connected to anything, > on which you can push a button "something went wrong, create a dump". > Then later I can fetch the said dump and inspect it. > > I'd like to include the whole journal, for the current boot, in a > binary format so that I can later do "journalctl --file > path/to/journal-dump.bin" from another machine. I understand that > internally everything is stored in /var/log/journal/, but > I guess that I cannot blindly tar/cp the .journal files, since this > would be racy. That should actually work fine. journald has no locking around journal files: the server that writes to the files and the client that reads them are not synchronized. The client is supposed to handle incomplete writes by simply suppressing display of the trailing, incomplete entries. This is a common code path, that is quite well tested these days. Hence, I should actually be fine to just copy the journal files as they are being written, the tools on the other side will possibly then see a file with records currently "in flight" that are referenced at some places but not others, but that should be totally OK, the tools should handle this, and this i no different from their local access. > So, is there an API to safely dump a big ".journal" file containing a > snapshot of "journalctl -b"? I could not find anything in the > documentation, sorry in advance if I missed something obvious. You can use "-o export" to dumb the files in an "export" format. But this is just about returning the data in a different format, it does not give you any synchronization guarantess since journalctl started that way will just read the data from the journal files unsynchronized as everyeone else too. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] [multiseat] Attach virtual input to seat1
On So, 03.09.23 00:46, LuKaRo (li...@lrose.de) wrote: > > $ sudo loginctl attach seat1 /sys/devices/virtual/input/input43 > Could not attach device: No such device > $ sudo loginctl attach seat1 /sys/devices/virtual/input/input44 > Could not attach device: No such device > $ sudo loginctl attach seat1 /sys/devices/virtual/input/input23 > Could not attach device: No such device > $ sudo loginctl attach seat1 /sys/devices/virtual/input/input22 > Could not attach device: No such device > $ sudo loginctl attach seat1 /sys/devices/virtual/input/input21 > Could not attach device: No such device > > Any idea why all of them fail, and what could be a possible > workaround? See my reply here: https://lists.freedesktop.org/archives/systemd-devel/2023-September/049470.html The key is that the udev property ID_FOR_SEAT is not set for these devices. (We should definitely generate a more useful error in that case.) Only devices that have that property set can be assigned to seats. ID_FOR_SEAT is supposed to carry some form of stable ID string we can identify the device with, that remains the same between reboots. We currently set ID_FOR_SEAT to useful values for PCI and USB devices, but not on other busses. In particular virtual devices are not covered. "input23" is not useful as an identifier string in ID_FOR_SEAT, because they are assigned in the order of probing, which typically is not stable. it should suffice setting the udev property via some udev rule to something reasonable, for the devices you add... I have no idea how that looks like for your specific type of devices. Lennart -- Lennart Poettering, Berlin
