[systemd-devel] IPv6 prefix delegation for 6rd tunnels
Is it possible to use prefix delegation when 6rd tunnel configured manually rather than received from DHCP? Provider Centurylink. They have following configuration: Connection Type: Tunnel 6rd DHCP Option: Disable IPv6 Prefix: 2602:: IPv6 Prefix Length: 24 IPv4 Border Router: 205.171.2.64 IPv4 Router Mask Length: 0 Tunnel MTU: 0 Tunnel TTL: 255 As far as I understood to use it in systemd-networkd I need to create netdev with tunnel type sit and IPv6RapidDeploymentPrefix=2602::/24. I assume that it will configure sit tunnel with /56 prefix. May I use DHCPPrefixDelegation for that? Or it need to be configured some other way? Thanks, Vitalii Aksonov
Re: [systemd-devel] Fedora 38 and signed PCR binding
On Sun, Nov 12, 2023 at 12:09 AM Aleksandar Kostadinov wrote: > > On Thu, Oct 12, 2023 at 1:14 AM Dan Streetman wrote: > > On Sun, Oct 8, 2023 at 8:09 AM Aleksandar Kostadinov > > wrote: > > ... > > > Here's what I did: > > > > sudo systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto > > > > --tpm2-public-key-pcrs=11 /dev/sda3 > > > > This probably isn't what you want, because you're specifying > > --tpm2-public-key-pcrs= but not --tpm2-public-key=, so the > > --tpm2-public-key-pcrs= doesn't actually do anything (it should > > probably either fail or at least print a warning). > > in man pages I see: > --tpm2-public-key= option accepts a path to a PEM encoded RSA >public key, to bind the encryption to. If this is not specified >explicitly, but a file tpm2-pcr-public-key.pem exists in one of the >directories /etc/systemd/, /run/systemd/, /usr/lib/systemd/ >(searched in this order), it is automatically used. > > I do have such a file. > > > Since you didn't specify --tpm2-pcrs=, it will default to use only > > PCR7, using the current value (at the time you ran > > systemd-cryptenroll). > > I specify --tpm2-public-key-pcrs=11, should I specify also > --tpm2-pcrs? I don't want to bind to plain PCRs. > > > Just for testing, can you try: > > sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs="" /dev/sda3 > > > > That will enroll your tpm with *no* pcr values, so it should always > > successfully unlock your volume using the tpm (note, you probably > > don't want to do this other than for testing). Then see if it uses the > > tpm to unlock the volume on boot. If so, you just need to get the > > specific PCR parameters correct (and make sure to supply your PEM > > public key to systemd-cryptenroll using --tpm2-public-key=), and > > provide the correct signature. > > This is a nice check actually. And in fact it does not open the volume > automatically. Which is super strange. As it worked with the normal > grub based boot process. > > sudo systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto > --tpm2-pcrs= /dev/sda3 > then removed `tpm2-measure-pcr=yes` from /etc/crypttab, then > `dracut-f` and finally `ukify ..` with the exact same arguments as > before. > > Did I miss something? > > Strange is that in `journalctl -b` I still see "Couldn't find > signature for this PCR bank, PCR index and public key." So I wonder > what could be broken and how to fix it. How to inspect the initrd > inside the UKI? And when I tried removing anything related to measuring PCRs from ukify, it still doesn't work but at least I don't see these messages in journalct. So issue appears to be related to how the UKI was generated. But again, no idea how to debug what is inside it. I don't know how to extract the parts. /usr/lib/systemd/ukify build --linux=/lib/modules/6.5.5-300.fc39.x86_64/vmlinuz --initrd=/boot/initramfs-6.5.5-300.fc39.x86_64.img --secureboot-private-key=/etc/secure_boot/db_custom.key --secureboot-certificate=/etc/secure_boot/db_custom.pem --sign-kernel --cmdline=@/etc/kernel/cmdline --output=/boot/efi/EFI/fedora/uki/vmlinuz.efi > <...>
Re: [systemd-devel] Fedora 38 and signed PCR binding
On Thu, Oct 12, 2023 at 1:14 AM Dan Streetman wrote: > On Sun, Oct 8, 2023 at 8:09 AM Aleksandar Kostadinov > wrote: > ... > > Here's what I did: > > > sudo systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto > > > --tpm2-public-key-pcrs=11 /dev/sda3 > > This probably isn't what you want, because you're specifying > --tpm2-public-key-pcrs= but not --tpm2-public-key=, so the > --tpm2-public-key-pcrs= doesn't actually do anything (it should > probably either fail or at least print a warning). in man pages I see: --tpm2-public-key= option accepts a path to a PEM encoded RSA public key, to bind the encryption to. If this is not specified explicitly, but a file tpm2-pcr-public-key.pem exists in one of the directories /etc/systemd/, /run/systemd/, /usr/lib/systemd/ (searched in this order), it is automatically used. I do have such a file. > Since you didn't specify --tpm2-pcrs=, it will default to use only > PCR7, using the current value (at the time you ran > systemd-cryptenroll). I specify --tpm2-public-key-pcrs=11, should I specify also --tpm2-pcrs? I don't want to bind to plain PCRs. > Just for testing, can you try: > sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs="" /dev/sda3 > > That will enroll your tpm with *no* pcr values, so it should always > successfully unlock your volume using the tpm (note, you probably > don't want to do this other than for testing). Then see if it uses the > tpm to unlock the volume on boot. If so, you just need to get the > specific PCR parameters correct (and make sure to supply your PEM > public key to systemd-cryptenroll using --tpm2-public-key=), and > provide the correct signature. This is a nice check actually. And in fact it does not open the volume automatically. Which is super strange. As it worked with the normal grub based boot process. sudo systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto --tpm2-pcrs= /dev/sda3 then removed `tpm2-measure-pcr=yes` from /etc/crypttab, then `dracut-f` and finally `ukify ..` with the exact same arguments as before. Did I miss something? Strange is that in `journalctl -b` I still see "Couldn't find signature for this PCR bank, PCR index and public key." So I wonder what could be broken and how to fix it. How to inspect the initrd inside the UKI? <...>
