Re: [systemd-devel] Fedora 38 and signed PCR binding
And one strange thing --tpm2-public-key-pcrs=11 doesn't seem to change how TMP is enrolled: $ sudo systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto --tpm2-pcrs="" /dev/sda3 Please enter current passphrase for disk /dev/sda3: *** This PCR set is already enrolled, executing no operation. $ sudo systemd-cryptenroll --wipe-slot=tpm2 --tpm2-pcrs="" --tpm2-device=auto --tpm2-public-key-pcrs=11 /dev/sda3 Please enter current passphrase for disk /dev/sda3: *** This PCR set is already enrolled, executing no operation. On Sat, Feb 10, 2024 at 10:23 PM Aleksandar Kostadinov wrote: > > Thanks a lot for the answers. Because without them I have no clue how > to progress. I'd highly appreciate your further guidance! > > On Fri, Nov 17, 2023 at 7:13 PM Dan Streetman wrote: > > <...> > > If you don't specify --tpm2-pcrs= at all, it will bind to PCR 7, even > > if you bind to a signature as well (at least this is the current > > behavior). > > > > If you want to bind only to a signature, you should use --tpm2-pcrs="" > > (i.e. empty string) to prevent binding to PCR 7. > > Got it. I see now with the luksDump what you mean > > How about crypttab? I tried this to no avail: > > luks- UUID= none > discard,tpm2-device=auto,tpm2-measure-pcr=yes,tpm2-pcrs= > > > <...> > > let's try manually unlocking it just to make sure the enrollment was > > ok, so after enrolling it try: > > > > systemd-cryptsetup [attach] test /dev/sda3 - tpm2-device=auto,headless=true > > Couldn't find signature for this PCR bank, PCR index and public key. > Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/sda3. > Couldn't find signature for this PCR bank, PCR index and public key. > No TPM2 metadata matching the current system state found in LUKS2 > header, falling back to traditional unlocking. > Password querying disabled via 'headless' option. > > I used `cryptsetup luksDump` to see the metadata and `cryptsetup > token` to eliminate stray token values. So now I only have two > keyslots - one for simple password and one for the TPM. And a single > token. I'll just paste it here, probably I later would need to > regenerate the volume to avoid exposure. > > Keyslots: > 0: luks2 > Key:512 bits > Priority: normal > Cipher: aes-xts-plain64 > Cipher key: 512 bits > PBKDF: argon2id > Time cost: 4 > Memory: 375564 > Threads:2 > Salt: fe 66 09 e8 71 ce 58 42 1d 5b 35 18 1f 3d fa bc > 01 7e 04 22 36 91 f3 68 fe 79 d2 02 f5 f6 08 a4 > AF stripes: 4000 > AF hash:sha256 > Area offset:32768 [bytes] > Area length:258048 [bytes] > Digest ID: 0 > 2: luks2 > Key:512 bits > Priority: normal > Cipher: aes-xts-plain64 > Cipher key: 512 bits > PBKDF: pbkdf2 > Hash: sha512 > Iterations: 1000 > Salt: 80 b9 1b e9 1d 11 e4 5b c3 93 ca 29 c1 d4 6d 8b > 62 e1 40 78 d3 ca c2 be 6b c8 d9 1d cd 2d 9c bf > AF stripes: 4000 > AF hash:sha512 > Area offset:548864 [bytes] > Area length:258048 [bytes] > Digest ID: 0 > Tokens: > 2: systemd-tpm2 > tpm2-hash-pcrs: > tpm2-pcr-bank:sha256 > tpm2-pubkey: > 2d 2d 2d 2d 2d 42 45 47 49 4e 20 50 55 42 4c 49 > 43 20 4b 45 59 2d 2d 2d 2d 2d 0a 4d 49 49 42 49 > 6a 41 4e 42 67 6b 71 68 6b 69 47 39 77 30 42 41 > 51 45 46 41 41 4f 43 41 51 38 41 4d 49 49 42 43 > 67 4b 43 41 51 45 41 36 44 6f 5a 5a 79 34 4d 43 > 47 69 50 51 34 65 68 38 4e 47 48 0a 59 6d 30 70 > 59 66 77 62 43 6f 39 56 79 56 74 61 56 78 47 4c > 6c 55 44 2f 53 38 44 52 57 32 43 4f 2f 4e 37 58 > 64 75 69 6f 68 7a 79 57 4c 4a 63 4a 46 73 35 79 > 70 7a 36 4d 2b 4c 6e 55 4a 6d 41 4a 0a 6b 75 44 > 78 43 39 67 47 72 4a 53 6e 58 48 34 55 30 6b 32 > 34 66 54 42 39 50 6f 70 6f 71 31 57 62 63 6e 51 > 30 6f 62 71 70 36 70 51 72 6d 4e 4b 6b 2f 63 49 > 34 46 4c 6d 2f 44 79 71 7a 66 31 45 43 0a 75 6a > 68 37 62 54 72 4c 35 32 79 34 2f 2f 6f 67 65 33 > 58 78 78 30 63 38 64 73 42 53 47 33 2b 33 71 2f > 79 46 6a 54 71 4d 6e 36 4a 34 62 38 6b 6a 36 52 > 2b 35 75 64 53 55 78 52 57 43 6e 37 72 4b 0a 76 > 33 47 2b 73 41 55 4a 59 72 6d 70 78 79 38 59 63 > 35 75 38 43 71 52 72 4c 39 69 7a 44 45 6c 53 6b > 47 53 56 49 5a 4a 45 71 68 43 31 31 4b 37 44 4b > 77 2b 6d 44 6a 79 35 31 62 30 45 55 61 54 51 0a > 2f 51 51 45 66 31 44 41 7a 4d 48 71 71 56 6a 73 > 70 74 6b 39 7a 53 36 4b 7a 36 2b 4a 52 47 78 47 > 2b 44 41 77 4f 35 2b 52 61 61 66 70 41 4a 55 47 > 7a 30 68 62 2f 4b 71 34 6c 69 34 63 53 5a 61 4a > 0a 51 77 49 44 41 51 41 42
Re: [systemd-devel] Fedora 38 and signed PCR binding
Thanks a lot for the answers. Because without them I have no clue how to progress. I'd highly appreciate your further guidance! On Fri, Nov 17, 2023 at 7:13 PM Dan Streetman wrote: > <...> > If you don't specify --tpm2-pcrs= at all, it will bind to PCR 7, even > if you bind to a signature as well (at least this is the current > behavior). > > If you want to bind only to a signature, you should use --tpm2-pcrs="" > (i.e. empty string) to prevent binding to PCR 7. Got it. I see now with the luksDump what you mean How about crypttab? I tried this to no avail: luks- UUID= none discard,tpm2-device=auto,tpm2-measure-pcr=yes,tpm2-pcrs= > <...> > let's try manually unlocking it just to make sure the enrollment was > ok, so after enrolling it try: > > systemd-cryptsetup [attach] test /dev/sda3 - tpm2-device=auto,headless=true Couldn't find signature for this PCR bank, PCR index and public key. Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/sda3. Couldn't find signature for this PCR bank, PCR index and public key. No TPM2 metadata matching the current system state found in LUKS2 header, falling back to traditional unlocking. Password querying disabled via 'headless' option. I used `cryptsetup luksDump` to see the metadata and `cryptsetup token` to eliminate stray token values. So now I only have two keyslots - one for simple password and one for the TPM. And a single token. I'll just paste it here, probably I later would need to regenerate the volume to avoid exposure. Keyslots: 0: luks2 Key:512 bits Priority: normal Cipher: aes-xts-plain64 Cipher key: 512 bits PBKDF: argon2id Time cost: 4 Memory: 375564 Threads:2 Salt: fe 66 09 e8 71 ce 58 42 1d 5b 35 18 1f 3d fa bc 01 7e 04 22 36 91 f3 68 fe 79 d2 02 f5 f6 08 a4 AF stripes: 4000 AF hash:sha256 Area offset:32768 [bytes] Area length:258048 [bytes] Digest ID: 0 2: luks2 Key:512 bits Priority: normal Cipher: aes-xts-plain64 Cipher key: 512 bits PBKDF: pbkdf2 Hash: sha512 Iterations: 1000 Salt: 80 b9 1b e9 1d 11 e4 5b c3 93 ca 29 c1 d4 6d 8b 62 e1 40 78 d3 ca c2 be 6b c8 d9 1d cd 2d 9c bf AF stripes: 4000 AF hash:sha512 Area offset:548864 [bytes] Area length:258048 [bytes] Digest ID: 0 Tokens: 2: systemd-tpm2 tpm2-hash-pcrs: tpm2-pcr-bank:sha256 tpm2-pubkey: 2d 2d 2d 2d 2d 42 45 47 49 4e 20 50 55 42 4c 49 43 20 4b 45 59 2d 2d 2d 2d 2d 0a 4d 49 49 42 49 6a 41 4e 42 67 6b 71 68 6b 69 47 39 77 30 42 41 51 45 46 41 41 4f 43 41 51 38 41 4d 49 49 42 43 67 4b 43 41 51 45 41 36 44 6f 5a 5a 79 34 4d 43 47 69 50 51 34 65 68 38 4e 47 48 0a 59 6d 30 70 59 66 77 62 43 6f 39 56 79 56 74 61 56 78 47 4c 6c 55 44 2f 53 38 44 52 57 32 43 4f 2f 4e 37 58 64 75 69 6f 68 7a 79 57 4c 4a 63 4a 46 73 35 79 70 7a 36 4d 2b 4c 6e 55 4a 6d 41 4a 0a 6b 75 44 78 43 39 67 47 72 4a 53 6e 58 48 34 55 30 6b 32 34 66 54 42 39 50 6f 70 6f 71 31 57 62 63 6e 51 30 6f 62 71 70 36 70 51 72 6d 4e 4b 6b 2f 63 49 34 46 4c 6d 2f 44 79 71 7a 66 31 45 43 0a 75 6a 68 37 62 54 72 4c 35 32 79 34 2f 2f 6f 67 65 33 58 78 78 30 63 38 64 73 42 53 47 33 2b 33 71 2f 79 46 6a 54 71 4d 6e 36 4a 34 62 38 6b 6a 36 52 2b 35 75 64 53 55 78 52 57 43 6e 37 72 4b 0a 76 33 47 2b 73 41 55 4a 59 72 6d 70 78 79 38 59 63 35 75 38 43 71 52 72 4c 39 69 7a 44 45 6c 53 6b 47 53 56 49 5a 4a 45 71 68 43 31 31 4b 37 44 4b 77 2b 6d 44 6a 79 35 31 62 30 45 55 61 54 51 0a 2f 51 51 45 66 31 44 41 7a 4d 48 71 71 56 6a 73 70 74 6b 39 7a 53 36 4b 7a 36 2b 4a 52 47 78 47 2b 44 41 77 4f 35 2b 52 61 61 66 70 41 4a 55 47 7a 30 68 62 2f 4b 71 34 6c 69 34 63 53 5a 61 4a 0a 51 77 49 44 41 51 41 42 0a 2d 2d 2d 2d 2d 45 4e 44 20 50 55 42 4c 49 43 20 4b 45 59 2d 2d 2d 2d 2d 0a tpm2-pubkey-pcrs: 11 tpm2-primary-alg: ecc tpm2-blob:00 7e 00 20 58 3d 8a 4d 57 a6 2d 48 45 58 ba 25 8d 22 5f 6b 62 c8 28 1e c0 b7 90 e3 62 98 30 27 19 c4 4b 68 00 10 92 fd 29 49 88 6f 6e 0d 30 51 be 63 c5 8e c3 2b d8 5b 9c 14 3b 11 33 d6 77 95 0a 01 5c 10 c0 d0 1a ff 34 df ea cf 21 a6 49 c9 c3 78 c9 1c a6 66 9c bd 25 62 5c 1a a2 14 19 58 74 09 e0 b8 f9 b0 9d 06 ec 60 95 9b 81 21 5d 1a 6a 40 57 a8 7d 08 5a c6 6e 62 c8 7e 18 5f d4 01 00 4e 00 08 00 0b 00 00 00 12 00 20 3f 8d 42 3c f9 cc ad 73 49 2f cb 95 3a bb
Re: [systemd-devel] Fedora 38 and signed PCR binding
On Sat, Nov 11, 2023 at 5:10 PM 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. ah ok, yeah that should be fine then. > > > 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. If you don't specify --tpm2-pcrs= at all, it will bind to PCR 7, even if you bind to a signature as well (at least this is the current behavior). If you want to bind only to a signature, you should use --tpm2-pcrs="" (i.e. empty string) to prevent binding to PCR 7. This is probably not the most intuitive default behavior, which we might want to change... > > > 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? let's try manually unlocking it just to make sure the enrollment was ok, so after enrolling it try: systemd-cryptsetup test /dev/sda3 - tpm2-device=auto,headless=true (you don't need headless=true, that only skips asking you for the luks password if the tpm unlocking didn't work) that should unlock the luks device and create the /dev/mapper/test device. if that doesn't work, then there's some problem with the tpm enrollment into your luks device. if it does work, then the problem is with your boot setup. my guess would be you aren't building the initrd with all the right bits needed to unlock it (you'll probably have to manually add in some crypt modules to the dracut call) > > 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? well you built the initrd before running ukify, so just take a look at it before you build the uki > > <...> >
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? <...>
Re: [systemd-devel] Fedora 38 and signed PCR binding
On Sun, Oct 8, 2023 at 8:09 AM Aleksandar Kostadinov
wrote:
>
> I've progressed past this point by upgrading to Fedora 39 Beta which
> apparently has a newer ukify version. The issue now though is that
> automatic unlock does not work. I need to enter password manually and
> I see no errors in console output.
>
> 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).
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).
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.
>
> > $ sudo cat /etc/crypttab
> > luks-### UUID=### none discard,tpm2-device=auto,tpm2-measure-pcr=yes
>
> > sudo dracut -f
>
> > /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 \
> > --pcr-private-key=/etc/systemd/tpm2-pcr-private-key.pem \
> > --pcr-public-key=/etc/systemd/tpm2-pcr-public-key.pem \
> > --phases='enter-initrd' \
> > --pcr-banks=sha1,sha256 \
> > --secureboot-private-key=/etc/secure_boot/db_custom.key \
> > --secureboot-certificate=/etc/secure_boot/db_custom.pem \
> > --sign-kernel \
> > --cmdline=@/etc/kernel/cmdline \
> > --measure \
> > --output=/boot/efi/EFI/fedora/uki/vmlinuz.efi
>
> > efibootmgr -c -d /dev/sda -p 1 -l /EFI/FEDORA/UKI/VMLINUZ.EFI -L "Fedora
> > UKI"
>
> The UKI entry now does boot. But waits for luks decryption password.
>
> I added a print line to the `ukify` executable to see the signature
> file generated.
>
> > {"sha1": [{"pcrs": [11], "pkfp":
> > "77cb92791d56699be04ab48bdc85adbd6e12ec2816241eadbe0859650684bee7", "pol":
> > "3d43ca831277c9a57f7741a23dca2896da9ece1417d1dc047c7a018014571580", "sig":
> > "hJ4fhnRPXmsEXdq6o5eVS9WbGyJJdp/Q+x8Op5EPp0JmnB79nuGZqtTK1tYaxjzgN6/w/Wq1k93p/owSks9I7SJ5wJ0ciA4Ruaou49HdK0eDBbDmJ+Bsb33t/tP7bgXrpz2KEzkpmxd9SkIfM/0cK9tHJfrlvuAZgNr9vr3zLBkaWGI2XkDhOCnujWvxatDX2L63IPUyAZ+CGqvSL95734MPsJ0VWeP3w0mBb9KfMw7jifWLVj+1A3V5iY2bK5HYCzMBab91XuQo2JjMRDfE33PlqkiRFq56AwpLkZAVijndFNHJj7zHrzXBBsKWsO+t3i6WVF4g2cmaISVs6ehIJw=="}],
> > "sha256": [{"pcrs": [11], "pkfp":
> > "77cb92791d56699be04ab48bdc85adbd6e12ec2816241eadbe0859650684bee7", "pol":
> > "76e24d931952b45046e001cac3ed6a6f9b76162fb3eb2366f704a6c360e720b1", "sig":
> > "t17dochSzptJyvNkrldHKSKF1WnVW6EncKNtvNftp7+VHJEb3/GL58/M67eRI7lDSxcTzKXEFCqgDUOJIBBod9hhY9i0QPirr7GOWOcV+3FsjFtT+q+SJ0QNBdYXCYvy5GwsrBe1RXRlw4JxfyNLXlaD4xVVsbEFd079yVK9HVd7LxIs8hVwDRTBMPnWgiglzinkYr6GxN7q0ipQAtVANyWOIWVMWAuYQ7fvZXqO4XEq1Bpu73vUxfMo+5g+GRJS0dXOnSXZWro8IssjZNaDimWOIgPPTmIDZVs4SptyLcQo9O6Z9YYScanP0jXtuJEkzCi7YxG+0QwHQQTp4mka2g=="}]}
>
> Any ideas what might be going wrong or how to further debug it?
>
> Thank you!
>
>
>
> On Fri, Sep 15, 2023 at 12:02 PM Aleksandar Kostadinov
> wrote:
> >
> > Will appreciate any pointers about debugging and fixing this!
> >
> > On Tue, Sep 12, 2023 at 2:55 AM Aleksandar Kostadinov
> > wrote:
> > >
> > > On Mon, Sep 11, 2023 at 2:57 PM Lennart Poettering
> > > wrote:
> > > >
> > > > On Mo, 11.09.23 14:48, Aleksandar Kostadinov (akost...@redhat.com)
> > > > wrote:
> > > >
> > > > > Hi again. I tried to boot from UKI to no avail.
> > > > >
> > > > > First created a "db" certificate
> > > > > > openssl req -newkey rsa:2048 -nodes -keyout db_arch.key -new -x509
> > > > > > -sha256 -days 3650 -subj "/CN=My DB cert/" -out db.pem
> > > > > > openssl x509 -outform DER -in db.pem -out db.crt
> > > > >
> > > > > Then uploaded it to secure boot trust VIA USB drive and the UEFI
> > > > > seup.
> > > > >
> > > > > Then created UKI:
> > > > > > /usr/lib/systemd/ukify \
> > > > > > /lib/modules/6.4.12-200.fc38.x86_64/vmlinuz \
> > > > > > /boot/initramfs-6.4.12-200.fc38.x86_64.img \
> > > > > >
> > > > > > --pcr-private-key=/etc/systemd/tpm2-pcr-private-key.pem \
> > > > > >
> > > > > > --pcr-public-key=/etc/systemd/tpm2-pcr-public-key.pem \
> > > > > >
Re: [systemd-devel] Fedora 38 and signed PCR binding
Console didn't show anything but I found these lines in system log.
> Oct 08 18:34:51 systemd-sysusers[228]: Creating group 'tss' with GID 59.
> Oct 08 18:34:51 systemd-sysusers[228]: Creating user 'tss' (Account used for
> TPM access) with UID 59 and GID 59.
> Oct 08 18:34:51 systemd-tmpfiles[232]: Failed to parse ACL
> "default:group:tss:rwx", ignoring: Invalid argument
>
> Oct 08 18:34:52 systemd[1]: Found device
> dev-disk-by\x2duuid-16b6da19\x2d8810\x2d49f8\x2d8923\x2dce803dacc3a1.device -
> UMIS_RTFTJ032VGD1EWX 3.
> Oct 08 18:34:52 systemd[1]: Starting
> systemd-cryptsetup@luks\x2d16b6da19\x2d8810\x2d49f8\x2d8923\x2dce803dacc3a1.service
> - Cryptography Setup for luks-16b6da19-8810-49f8-8923-ce803dacc3a1...
>
> Oct 08 18:34:53 systemd-cryptsetup[437]: Couldn't find signature for this PCR
> bank, PCR index and public key.
> Oct 08 18:34:53 systemd-cryptsetup[437]: Set cipher aes, mode xts-plain64,
> key size 512 bits for device
> /dev/disk/by-uuid/16b6da19-8810-49f8-8923-ce803dacc3a1.
> Oct 08 18:34:53 systemd-cryptsetup[437]: Automatically discovered security
> TPM2 token unlocks volume.
> Oct 08 18:34:54 systemd-cryptsetup[437]: Couldn't find signature for this PCR
> bank, PCR index and public key.
> Oct 08 18:34:54 systemd-cryptsetup[437]: TPM2 operation failed, falling back
> to traditional unlocking: No such device or address
>
> Oct 08 18:35:24 systemd-cryptsetup[437]: Set cipher aes, mode xts-plain64,
> key size 512 bits for device
> /dev/disk/by-uuid/16b6da19-8810-49f8-8923-ce803dacc3a1.
> Oct 08 18:35:26 systemd-cryptsetup[437]: Successfully extended PCR index 15
> with
> 'cryptsetup:luks-16b6da19-8810-49f8-8923-ce803dacc3a1:16b6da19-8810-49f8-8923-ce803dacc3a1'
> and volume key (banks sha1, sha256).
> Oct 08 18:35:26 systemd[1]: Finished
> systemd-cryptsetup@luks\x2d16b6da19\x2d8810\x2d49f8\x2d8923\x2dce803dacc3a1.service
> - Cryptography Setup for luks-16b6da19-8810-49f8-8923-ce803dacc3a1.
How to know what is the issue causing "Couldn't find signature for
this PCR bank, PCR index and public key." ?
On Sun, Oct 8, 2023 at 3:20 PM Aleksandar Kostadinov
wrote:
>
> Also forgot to mention how I have setup the RSA keys:
>
> > 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
>
> and
>
> > echo "add_dracutmodules+=\" tpm2-tss \"" > /etc/dracut.conf.d/tpm2.conf
>
> The secure boot key I assume is alright because I have secure boot
> enabled and it boots the kernel.
>
> On Sun, Oct 8, 2023 at 3:08 PM Aleksandar Kostadinov
> wrote:
> >
> > I've progressed past this point by upgrading to Fedora 39 Beta which
> > apparently has a newer ukify version. The issue now though is that
> > automatic unlock does not work. I need to enter password manually and
> > I see no errors in console output.
> >
> > Here's what I did:
> > > sudo systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto
> > > --tpm2-public-key-pcrs=11 /dev/sda3
> >
> > > $ sudo cat /etc/crypttab
> > > luks-### UUID=### none discard,tpm2-device=auto,tpm2-measure-pcr=yes
> >
> > > sudo dracut -f
> >
> > > /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 \
> > > --pcr-private-key=/etc/systemd/tpm2-pcr-private-key.pem \
> > > --pcr-public-key=/etc/systemd/tpm2-pcr-public-key.pem \
> > > --phases='enter-initrd' \
> > > --pcr-banks=sha1,sha256 \
> > > --secureboot-private-key=/etc/secure_boot/db_custom.key \
> > > --secureboot-certificate=/etc/secure_boot/db_custom.pem \
> > > --sign-kernel \
> > > --cmdline=@/etc/kernel/cmdline \
> > > --measure \
> > > --output=/boot/efi/EFI/fedora/uki/vmlinuz.efi
> >
> > > efibootmgr -c -d /dev/sda -p 1 -l /EFI/FEDORA/UKI/VMLINUZ.EFI -L "Fedora
> > > UKI"
> >
> > The UKI entry now does boot. But waits for luks decryption password.
> >
> > I added a print line to the `ukify` executable to see the signature
> > file generated.
> >
> > > {"sha1": [{"pcrs": [11], "pkfp":
> > > "77cb92791d56699be04ab48bdc85adbd6e12ec2816241eadbe0859650684bee7",
> > > "pol":
> > > "3d43ca831277c9a57f7741a23dca2896da9ece1417d1dc047c7a018014571580",
> > > "sig":
> > > "hJ4fhnRPXmsEXdq6o5eVS9WbGyJJdp/Q+x8Op5EPp0JmnB79nuGZqtTK1tYaxjzgN6/w/Wq1k93p/owSks9I7SJ5wJ0ciA4Ruaou49HdK0eDBbDmJ+Bsb33t/tP7bgXrpz2KEzkpmxd9SkIfM/0cK9tHJfrlvuAZgNr9vr3zLBkaWGI2XkDhOCnujWvxatDX2L63IPUyAZ+CGqvSL95734MPsJ0VWeP3w0mBb9KfMw7jifWLVj+1A3V5iY2bK5HYCzMBab91XuQo2JjMRDfE33PlqkiRFq56AwpLkZAVijndFNHJj7zHrzXBBsKWsO+t3i6WVF4g2cmaISVs6ehIJw=="}],
> > > "sha256": [{"pcrs": [11], "pkfp":
> > > "77cb92791d56699be04ab48bdc85adbd6e12ec2816241eadbe0859650684bee7",
> > > "pol":
> > >
Re: [systemd-devel] Fedora 38 and signed PCR binding
Also forgot to mention how I have setup the RSA keys:
> 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
and
> echo "add_dracutmodules+=\" tpm2-tss \"" > /etc/dracut.conf.d/tpm2.conf
The secure boot key I assume is alright because I have secure boot
enabled and it boots the kernel.
On Sun, Oct 8, 2023 at 3:08 PM Aleksandar Kostadinov
wrote:
>
> I've progressed past this point by upgrading to Fedora 39 Beta which
> apparently has a newer ukify version. The issue now though is that
> automatic unlock does not work. I need to enter password manually and
> I see no errors in console output.
>
> Here's what I did:
> > sudo systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto
> > --tpm2-public-key-pcrs=11 /dev/sda3
>
> > $ sudo cat /etc/crypttab
> > luks-### UUID=### none discard,tpm2-device=auto,tpm2-measure-pcr=yes
>
> > sudo dracut -f
>
> > /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 \
> > --pcr-private-key=/etc/systemd/tpm2-pcr-private-key.pem \
> > --pcr-public-key=/etc/systemd/tpm2-pcr-public-key.pem \
> > --phases='enter-initrd' \
> > --pcr-banks=sha1,sha256 \
> > --secureboot-private-key=/etc/secure_boot/db_custom.key \
> > --secureboot-certificate=/etc/secure_boot/db_custom.pem \
> > --sign-kernel \
> > --cmdline=@/etc/kernel/cmdline \
> > --measure \
> > --output=/boot/efi/EFI/fedora/uki/vmlinuz.efi
>
> > efibootmgr -c -d /dev/sda -p 1 -l /EFI/FEDORA/UKI/VMLINUZ.EFI -L "Fedora
> > UKI"
>
> The UKI entry now does boot. But waits for luks decryption password.
>
> I added a print line to the `ukify` executable to see the signature
> file generated.
>
> > {"sha1": [{"pcrs": [11], "pkfp":
> > "77cb92791d56699be04ab48bdc85adbd6e12ec2816241eadbe0859650684bee7", "pol":
> > "3d43ca831277c9a57f7741a23dca2896da9ece1417d1dc047c7a018014571580", "sig":
> > "hJ4fhnRPXmsEXdq6o5eVS9WbGyJJdp/Q+x8Op5EPp0JmnB79nuGZqtTK1tYaxjzgN6/w/Wq1k93p/owSks9I7SJ5wJ0ciA4Ruaou49HdK0eDBbDmJ+Bsb33t/tP7bgXrpz2KEzkpmxd9SkIfM/0cK9tHJfrlvuAZgNr9vr3zLBkaWGI2XkDhOCnujWvxatDX2L63IPUyAZ+CGqvSL95734MPsJ0VWeP3w0mBb9KfMw7jifWLVj+1A3V5iY2bK5HYCzMBab91XuQo2JjMRDfE33PlqkiRFq56AwpLkZAVijndFNHJj7zHrzXBBsKWsO+t3i6WVF4g2cmaISVs6ehIJw=="}],
> > "sha256": [{"pcrs": [11], "pkfp":
> > "77cb92791d56699be04ab48bdc85adbd6e12ec2816241eadbe0859650684bee7", "pol":
> > "76e24d931952b45046e001cac3ed6a6f9b76162fb3eb2366f704a6c360e720b1", "sig":
> > "t17dochSzptJyvNkrldHKSKF1WnVW6EncKNtvNftp7+VHJEb3/GL58/M67eRI7lDSxcTzKXEFCqgDUOJIBBod9hhY9i0QPirr7GOWOcV+3FsjFtT+q+SJ0QNBdYXCYvy5GwsrBe1RXRlw4JxfyNLXlaD4xVVsbEFd079yVK9HVd7LxIs8hVwDRTBMPnWgiglzinkYr6GxN7q0ipQAtVANyWOIWVMWAuYQ7fvZXqO4XEq1Bpu73vUxfMo+5g+GRJS0dXOnSXZWro8IssjZNaDimWOIgPPTmIDZVs4SptyLcQo9O6Z9YYScanP0jXtuJEkzCi7YxG+0QwHQQTp4mka2g=="}]}
>
> Any ideas what might be going wrong or how to further debug it?
>
> Thank you!
>
>
>
> On Fri, Sep 15, 2023 at 12:02 PM Aleksandar Kostadinov
> wrote:
> >
> > Will appreciate any pointers about debugging and fixing this!
> >
> > On Tue, Sep 12, 2023 at 2:55 AM Aleksandar Kostadinov
> > wrote:
> > >
> > > On Mon, Sep 11, 2023 at 2:57 PM Lennart Poettering
> > > wrote:
> > > >
> > > > On Mo, 11.09.23 14:48, Aleksandar Kostadinov (akost...@redhat.com)
> > > > wrote:
> > > >
> > > > > Hi again. I tried to boot from UKI to no avail.
> > > > >
> > > > > First created a "db" certificate
> > > > > > openssl req -newkey rsa:2048 -nodes -keyout db_arch.key -new -x509
> > > > > > -sha256 -days 3650 -subj "/CN=My DB cert/" -out db.pem
> > > > > > openssl x509 -outform DER -in db.pem -out db.crt
> > > > >
> > > > > Then uploaded it to secure boot trust VIA USB drive and the UEFI
> > > > > seup.
> > > > >
> > > > > Then created UKI:
> > > > > > /usr/lib/systemd/ukify \
> > > > > > /lib/modules/6.4.12-200.fc38.x86_64/vmlinuz \
> > > > > > /boot/initramfs-6.4.12-200.fc38.x86_64.img \
> > > > > >
> > > > > > --pcr-private-key=/etc/systemd/tpm2-pcr-private-key.pem \
> > > > > >
> > > > > > --pcr-public-key=/etc/systemd/tpm2-pcr-public-key.pem \
> > > > > > --phases='enter-initrd' \
> > > > > > --pcr-banks=sha1,sha256 \
> > > > > > --secureboot-private-key=/etc/secure_boot/db.key \
> > > > > > --secureboot-certificate=/etc/secure_boot/db.pem \
> > > > > > --sign-kernel \
> > > > > > --cmdline='ro rhgb'
> > > > >
> > > > > Then added a boot entry:
> > > > > > efibootmgr -c -d /dev/sda -p 1 -l /EFI/FEDORA/UKI/VMLINUZ612.EFI -L
> > > > > > "Fedora UKI"
> > > > >
> > > > > Unfortunately
Re: [systemd-devel] Fedora 38 and signed PCR binding
I've progressed past this point by upgrading to Fedora 39 Beta which
apparently has a newer ukify version. The issue now though is that
automatic unlock does not work. I need to enter password manually and
I see no errors in console output.
Here's what I did:
> sudo systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto
> --tpm2-public-key-pcrs=11 /dev/sda3
> $ sudo cat /etc/crypttab
> luks-### UUID=### none discard,tpm2-device=auto,tpm2-measure-pcr=yes
> sudo dracut -f
> /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 \
> --pcr-private-key=/etc/systemd/tpm2-pcr-private-key.pem \
> --pcr-public-key=/etc/systemd/tpm2-pcr-public-key.pem \
> --phases='enter-initrd' \
> --pcr-banks=sha1,sha256 \
> --secureboot-private-key=/etc/secure_boot/db_custom.key \
> --secureboot-certificate=/etc/secure_boot/db_custom.pem \
> --sign-kernel \
> --cmdline=@/etc/kernel/cmdline \
> --measure \
> --output=/boot/efi/EFI/fedora/uki/vmlinuz.efi
> efibootmgr -c -d /dev/sda -p 1 -l /EFI/FEDORA/UKI/VMLINUZ.EFI -L "Fedora UKI"
The UKI entry now does boot. But waits for luks decryption password.
I added a print line to the `ukify` executable to see the signature
file generated.
> {"sha1": [{"pcrs": [11], "pkfp":
> "77cb92791d56699be04ab48bdc85adbd6e12ec2816241eadbe0859650684bee7", "pol":
> "3d43ca831277c9a57f7741a23dca2896da9ece1417d1dc047c7a018014571580", "sig":
> "hJ4fhnRPXmsEXdq6o5eVS9WbGyJJdp/Q+x8Op5EPp0JmnB79nuGZqtTK1tYaxjzgN6/w/Wq1k93p/owSks9I7SJ5wJ0ciA4Ruaou49HdK0eDBbDmJ+Bsb33t/tP7bgXrpz2KEzkpmxd9SkIfM/0cK9tHJfrlvuAZgNr9vr3zLBkaWGI2XkDhOCnujWvxatDX2L63IPUyAZ+CGqvSL95734MPsJ0VWeP3w0mBb9KfMw7jifWLVj+1A3V5iY2bK5HYCzMBab91XuQo2JjMRDfE33PlqkiRFq56AwpLkZAVijndFNHJj7zHrzXBBsKWsO+t3i6WVF4g2cmaISVs6ehIJw=="}],
> "sha256": [{"pcrs": [11], "pkfp":
> "77cb92791d56699be04ab48bdc85adbd6e12ec2816241eadbe0859650684bee7", "pol":
> "76e24d931952b45046e001cac3ed6a6f9b76162fb3eb2366f704a6c360e720b1", "sig":
> "t17dochSzptJyvNkrldHKSKF1WnVW6EncKNtvNftp7+VHJEb3/GL58/M67eRI7lDSxcTzKXEFCqgDUOJIBBod9hhY9i0QPirr7GOWOcV+3FsjFtT+q+SJ0QNBdYXCYvy5GwsrBe1RXRlw4JxfyNLXlaD4xVVsbEFd079yVK9HVd7LxIs8hVwDRTBMPnWgiglzinkYr6GxN7q0ipQAtVANyWOIWVMWAuYQ7fvZXqO4XEq1Bpu73vUxfMo+5g+GRJS0dXOnSXZWro8IssjZNaDimWOIgPPTmIDZVs4SptyLcQo9O6Z9YYScanP0jXtuJEkzCi7YxG+0QwHQQTp4mka2g=="}]}
Any ideas what might be going wrong or how to further debug it?
Thank you!
On Fri, Sep 15, 2023 at 12:02 PM Aleksandar Kostadinov
wrote:
>
> Will appreciate any pointers about debugging and fixing this!
>
> On Tue, Sep 12, 2023 at 2:55 AM Aleksandar Kostadinov
> wrote:
> >
> > On Mon, Sep 11, 2023 at 2:57 PM Lennart Poettering
> > wrote:
> > >
> > > On Mo, 11.09.23 14:48, Aleksandar Kostadinov (akost...@redhat.com) wrote:
> > >
> > > > Hi again. I tried to boot from UKI to no avail.
> > > >
> > > > First created a "db" certificate
> > > > > openssl req -newkey rsa:2048 -nodes -keyout db_arch.key -new -x509
> > > > > -sha256 -days 3650 -subj "/CN=My DB cert/" -out db.pem
> > > > > openssl x509 -outform DER -in db.pem -out db.crt
> > > >
> > > > Then uploaded it to secure boot trust VIA USB drive and the UEFI seup.
> > > >
> > > > Then created UKI:
> > > > > /usr/lib/systemd/ukify \
> > > > > /lib/modules/6.4.12-200.fc38.x86_64/vmlinuz \
> > > > > /boot/initramfs-6.4.12-200.fc38.x86_64.img \
> > > > >
> > > > > --pcr-private-key=/etc/systemd/tpm2-pcr-private-key.pem \
> > > > > --pcr-public-key=/etc/systemd/tpm2-pcr-public-key.pem
> > > > > \
> > > > > --phases='enter-initrd' \
> > > > > --pcr-banks=sha1,sha256 \
> > > > > --secureboot-private-key=/etc/secure_boot/db.key \
> > > > > --secureboot-certificate=/etc/secure_boot/db.pem \
> > > > > --sign-kernel \
> > > > > --cmdline='ro rhgb'
> > > >
> > > > Then added a boot entry:
> > > > > efibootmgr -c -d /dev/sda -p 1 -l /EFI/FEDORA/UKI/VMLINUZ612.EFI -L
> > > > > "Fedora UKI"
> > > >
> > > > Unfortunately when trying to boot this I get:
> > > > > Bad kernel image: Load Error
> > >
> > > That suggests the kernel you picked does not carry a correct PE/MZ
> > > signature. i.e. we generate that error typically if we can#t jump into
> > > it because it doesn't come with the right PE headers.
> >
> > This is just a standard kernel coming with Fedora 38. I didn't modify
> > it. Also initrd as generated by dracut.
> >
> > > $ hexdump -C -n4 < /lib/modules/6.4.12-200.fc38.x86_64/vmlinuz
> > > 4d 5a ea 07 |MZ..|
> > > $ file /lib/modules/6.4.12-200.fc38.x86_64/vmlinuz
> > > /lib/modules/6.4.12-200.fc38.x86_64/vmlinuz: Linux
Re: [systemd-devel] Fedora 38 and signed PCR binding
Will appreciate any pointers about debugging and fixing this! On Tue, Sep 12, 2023 at 2:55 AM Aleksandar Kostadinov wrote: > > On Mon, Sep 11, 2023 at 2:57 PM Lennart Poettering > wrote: > > > > On Mo, 11.09.23 14:48, Aleksandar Kostadinov (akost...@redhat.com) wrote: > > > > > Hi again. I tried to boot from UKI to no avail. > > > > > > First created a "db" certificate > > > > openssl req -newkey rsa:2048 -nodes -keyout db_arch.key -new -x509 > > > > -sha256 -days 3650 -subj "/CN=My DB cert/" -out db.pem > > > > openssl x509 -outform DER -in db.pem -out db.crt > > > > > > Then uploaded it to secure boot trust VIA USB drive and the UEFI seup. > > > > > > Then created UKI: > > > > /usr/lib/systemd/ukify \ > > > > /lib/modules/6.4.12-200.fc38.x86_64/vmlinuz \ > > > > /boot/initramfs-6.4.12-200.fc38.x86_64.img \ > > > > --pcr-private-key=/etc/systemd/tpm2-pcr-private-key.pem > > > > \ > > > > --pcr-public-key=/etc/systemd/tpm2-pcr-public-key.pem \ > > > > --phases='enter-initrd' \ > > > > --pcr-banks=sha1,sha256 \ > > > > --secureboot-private-key=/etc/secure_boot/db.key \ > > > > --secureboot-certificate=/etc/secure_boot/db.pem \ > > > > --sign-kernel \ > > > > --cmdline='ro rhgb' > > > > > > Then added a boot entry: > > > > efibootmgr -c -d /dev/sda -p 1 -l /EFI/FEDORA/UKI/VMLINUZ612.EFI -L > > > > "Fedora UKI" > > > > > > Unfortunately when trying to boot this I get: > > > > Bad kernel image: Load Error > > > > That suggests the kernel you picked does not carry a correct PE/MZ > > signature. i.e. we generate that error typically if we can#t jump into > > it because it doesn't come with the right PE headers. > > This is just a standard kernel coming with Fedora 38. I didn't modify > it. Also initrd as generated by dracut. > > > $ hexdump -C -n4 < /lib/modules/6.4.12-200.fc38.x86_64/vmlinuz > > 4d 5a ea 07 |MZ..| > > $ file /lib/modules/6.4.12-200.fc38.x86_64/vmlinuz > > /lib/modules/6.4.12-200.fc38.x86_64/vmlinuz: Linux kernel x86 boot > > executable bzImage, version 6.4.12-200.fc38.x86_64 > > (mockbuild@30894952d3244f1ab967aeda9ed417f6) #1 SMP PREEMPT_DYNAMIC Wed Aug > > 23 17:46:49 UTC 2023, RO-rootFS, swap_dev 0XD, Normal VGA > > Any suggestions on how to fix it? > > If it matters -- ukify 253 (253.7-1.fc38)
Re: [systemd-devel] Fedora 38 and signed PCR binding
On Mon, Sep 11, 2023 at 2:57 PM Lennart Poettering wrote: > > On Mo, 11.09.23 14:48, Aleksandar Kostadinov (akost...@redhat.com) wrote: > > > Hi again. I tried to boot from UKI to no avail. > > > > First created a "db" certificate > > > openssl req -newkey rsa:2048 -nodes -keyout db_arch.key -new -x509 > > > -sha256 -days 3650 -subj "/CN=My DB cert/" -out db.pem > > > openssl x509 -outform DER -in db.pem -out db.crt > > > > Then uploaded it to secure boot trust VIA USB drive and the UEFI seup. > > > > Then created UKI: > > > /usr/lib/systemd/ukify \ > > > /lib/modules/6.4.12-200.fc38.x86_64/vmlinuz \ > > > /boot/initramfs-6.4.12-200.fc38.x86_64.img \ > > > --pcr-private-key=/etc/systemd/tpm2-pcr-private-key.pem \ > > > --pcr-public-key=/etc/systemd/tpm2-pcr-public-key.pem \ > > > --phases='enter-initrd' \ > > > --pcr-banks=sha1,sha256 \ > > > --secureboot-private-key=/etc/secure_boot/db.key \ > > > --secureboot-certificate=/etc/secure_boot/db.pem \ > > > --sign-kernel \ > > > --cmdline='ro rhgb' > > > > Then added a boot entry: > > > efibootmgr -c -d /dev/sda -p 1 -l /EFI/FEDORA/UKI/VMLINUZ612.EFI -L > > > "Fedora UKI" > > > > Unfortunately when trying to boot this I get: > > > Bad kernel image: Load Error > > That suggests the kernel you picked does not carry a correct PE/MZ > signature. i.e. we generate that error typically if we can#t jump into > it because it doesn't come with the right PE headers. This is just a standard kernel coming with Fedora 38. I didn't modify it. Also initrd as generated by dracut. > $ hexdump -C -n4 < /lib/modules/6.4.12-200.fc38.x86_64/vmlinuz > 4d 5a ea 07 |MZ..| > $ file /lib/modules/6.4.12-200.fc38.x86_64/vmlinuz > /lib/modules/6.4.12-200.fc38.x86_64/vmlinuz: Linux kernel x86 boot executable > bzImage, version 6.4.12-200.fc38.x86_64 > (mockbuild@30894952d3244f1ab967aeda9ed417f6) #1 SMP PREEMPT_DYNAMIC Wed Aug > 23 17:46:49 UTC 2023, RO-rootFS, swap_dev 0XD, Normal VGA Any suggestions on how to fix it? If it matters -- ukify 253 (253.7-1.fc38)
Re: [systemd-devel] Fedora 38 and signed PCR binding
On Mo, 11.09.23 14:48, Aleksandar Kostadinov (akost...@redhat.com) wrote: > Hi again. I tried to boot from UKI to no avail. > > First created a "db" certificate > > openssl req -newkey rsa:2048 -nodes -keyout db_arch.key -new -x509 -sha256 > > -days 3650 -subj "/CN=My DB cert/" -out db.pem > > openssl x509 -outform DER -in db.pem -out db.crt > > Then uploaded it to secure boot trust VIA USB drive and the UEFI seup. > > Then created UKI: > > /usr/lib/systemd/ukify \ > > /lib/modules/6.4.12-200.fc38.x86_64/vmlinuz \ > > /boot/initramfs-6.4.12-200.fc38.x86_64.img \ > > --pcr-private-key=/etc/systemd/tpm2-pcr-private-key.pem \ > > --pcr-public-key=/etc/systemd/tpm2-pcr-public-key.pem \ > > --phases='enter-initrd' \ > > --pcr-banks=sha1,sha256 \ > > --secureboot-private-key=/etc/secure_boot/db.key \ > > --secureboot-certificate=/etc/secure_boot/db.pem \ > > --sign-kernel \ > > --cmdline='ro rhgb' > > Then added a boot entry: > > efibootmgr -c -d /dev/sda -p 1 -l /EFI/FEDORA/UKI/VMLINUZ612.EFI -L "Fedora > > UKI" > > Unfortunately when trying to boot this I get: > > Bad kernel image: Load Error That suggests the kernel you picked does not carry a correct PE/MZ signature. i.e. we generate that error typically if we can#t jump into it because it doesn't come with the right PE headers. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Fedora 38 and signed PCR binding
Hi again. I tried to boot from UKI to no avail. First created a "db" certificate > openssl req -newkey rsa:2048 -nodes -keyout db_arch.key -new -x509 -sha256 > -days 3650 -subj "/CN=My DB cert/" -out db.pem > openssl x509 -outform DER -in db.pem -out db.crt Then uploaded it to secure boot trust VIA USB drive and the UEFI seup. Then created UKI: > /usr/lib/systemd/ukify \ > /lib/modules/6.4.12-200.fc38.x86_64/vmlinuz \ > /boot/initramfs-6.4.12-200.fc38.x86_64.img \ > --pcr-private-key=/etc/systemd/tpm2-pcr-private-key.pem \ > --pcr-public-key=/etc/systemd/tpm2-pcr-public-key.pem \ > --phases='enter-initrd' \ > --pcr-banks=sha1,sha256 \ > --secureboot-private-key=/etc/secure_boot/db.key \ > --secureboot-certificate=/etc/secure_boot/db.pem \ > --sign-kernel \ > --cmdline='ro rhgb' Then added a boot entry: > efibootmgr -c -d /dev/sda -p 1 -l /EFI/FEDORA/UKI/VMLINUZ612.EFI -L "Fedora > UKI" Unfortunately when trying to boot this I get: > Bad kernel image: Load Error It seems like trying to boot because momentarily I see a mouse cursor and then terminal resets back and I see the error message. Actually I see it twice before the grub bootloader entry gets picked up. Any ideas what I might be doing wrong? This is on Fedora 38. On Tue, Sep 5, 2023 at 1:20 PM Lennart Poettering wrote: > > 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: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] Fedora 38 and signed PCR binding
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? Also forgot to post link to article in my last email, here it goes [2] [1] https://github.com/systemd/systemd/pull/24351/files#r961978027 [2] https://fedoramagazine.org/use-systemd-cryptenroll-with-fido-u2f-or-tpm2-to-decrypt-your-disk/ On Sat, Sep 2, 2023 at 10:18 PM Aleksandar Kostadinov 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? > > Thank you.
[systemd-devel] Fedora 38 and signed PCR binding
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? Thank you.
