2 Replies Latest reply on Aug 6, 2019 1:38 PM by 4008922

    LUKS volume does not get unsealed by the TPM after a update

    4008922

      Hello everyone,

      I'm performing a Kickstart-installation from a USB-Stick of Oracle-Linux 7.6 on a Dell Optiplex 3060 where I also encrypt the volume and bind it to the TPM to unlock it automatically:

      clevis luks bind -d /dev/nvme0n1p3 tpm2 '{"pcr_ids":"7"}' 
      $ luksmeta show -d /dev/nvme0n1p3
      0 active empty
      1 active cb6e8904-81ff-40da-a84a-07ab9ab5715e
      2 inactive empty
      (...)

      After experimenting for quite some time this works fine and how I need it. When the system boots the volume gets automatically unlocked after around a minute. As you can see above, I bind it to PCR7, so how I understood this topic, a update to a new kernel singed by the same vendor should not alter the hash of the TPM and furthermore the automatic unlock should still work. But unfortunately after yum updateand a reboot that is not the case and it says

      tpm tpm0: A TPM error (357) occurred flushing context
      dracut-initqueue[355]: Unsealing jwk from TPM failed!
      tpm tpm0: tpm_try_transmit: tpm_send: error -5

      After the (first) reboot after the update, trying to execute the clevis luks bind-command once more failes (manual unlocking is still possible) :

      $ clevis luks bind -d /dev/nvme0n1p3 tpm2 '{"pcr_ids":"7"}'
      ERROR: Failed tpm session start auth with params
      ERROR: Error starting the policy session.

      After another reboot I am able to bind it and the automatic unlocking also works again.

      $ luksmeta show -d /dev/nvme0n1p3
      0   active empty
      1   active cb6e8904-81ff-40da-a84a-07ab9ab5715e
      2   active cb6e8904-81ff-40da-a84a-07ab9ab5715e
      3 inactive empty
      (...)

      I compared the Key IDs of the originally installed kernel, with which the unlocking works before the update, with the new one and they are identical, but I'm not sure, if those signatures are the relevant ones

      $ uname -r
      4.14.35-1818.3.3.el7uek.x86_64
      $ find / -type f -name kernel-uek*.rpm
      (...)
      /run/media/sklera/OL-7_6/Packages/kernel-uek-4.14.35-1818.3.3.el7uek.x86_64.rpm
      /var/cache/yum/x86_64/7Server/VSE_Oracle_Linux_7_OEL_7_UEK5/packages/kernel-uek-4.14.35-1902.3.1.el7uek.x86_64.rpm

      Original kernel:

      $ rpm -qpi /run/media/sklera/OL-7_6/Packages/kernel-uek-4.14.35-1818.3.3.el7uek.x86_64.rpm
      (...)
      Signature   : RSA/SHA256, Tue 25 Sep 2018 12:11:55 AM CEST, Key ID 72f97b74ec551f03

      New kernel:

      $ rpm -qpi /var/cache/yum/x86_64/7Server/VSE_Oracle_Linux_7_OEL_7_UEK5/packages/kernel-uek-4.14.35-1902.3.1.el7uek.x86_64.rpm
      (...)
      Signature   : RSA/SHA256, Tue 25 Jun 2019 06:43:44 AM CEST, Key ID 72f97b74ec551f03

      So my questions are:

      • How can I tell why the unlocking does fail after the update and why couldn't I bind it once more the fist time?
      • Are the signatures of the packages that I compared the correct ones?

       

      I would appreciate your help and thanks beforehand.

       

      Regards,
      Markus

        • 1. Re: LUKS volume does not get unsealed by the TPM after a update
          Dude!

          I suggest to find out if the problem is kernel related. This should be very easy to determine since you can still boot the previous kernel from the boot menu. Does this fix the problem? Next, I suggest to compare the kernel boot parameters of the working and failing kernel. Any differences? If this looks fine, does or did the boot device have sufficient free space available to complete the upgrade?

          • 2. Re: LUKS volume does not get unsealed by the TPM after a update
            4008922

            Thank you very much for your reply and suggestion. A couple of days ago I already tried to boot with the old kernel and as far as I remember, it did work back then. However, I just tried to boot the system with the old kernel and it resulted in an error. Unfortunately I did not write the error down.

            Because I tried to get dropbear working during the boot, I edited the grub.cfg and because of that I just perform a fresh installation at this moment to eleminate problems regarding that. I will post an update soon.

             

            At the time, I perform the upgrade manually and it finishes without errors and the boot partition has  ~600MiB available space.

             

            Edit: The fresh installation has finished - automatic unlocking worked - I updated the system - automatic unlocking failed (as usual)

            And I can't boot with the old kernel because I get the following error directly after I select the boot-menu-entry:

            error: /vmlinuz-4-14.... has invalid signature

            error: you need to load the kernel first.

            The entries in /boot/efi/EFI/redhat/grub.cfg before and after the update are/were:

             

            menuentry 'Oracle Linux Server (4.14.35-1818.3.3.el7uek.x86_64 with Unbreakable Enterprise Kernel) 7.6' --class oracle --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.14.35-1818.3.3.el7uek.x86_64-advanced-42f19163-ae4c-422e-8e8e-2564f8c28681' {

                    load_video

                    set gfxpayload=keep

                    insmod gzio

                    insmod part_gpt

                    insmod ext2

                    if [ x$feature_platform_search_hint = xy ]; then

                      search --no-floppy --fs-uuid --set=root  a41575ba-19e7-4729-8fff-769de4c6333f

                    else

                      search --no-floppy --fs-uuid --set=root a41575ba-19e7-4729-8fff-769de4c6333f

                    fi

                    linuxefi /vmlinuz-4.14.35-1818.3.3.el7uek.x86_64 root=/dev/mapper/vg_oracle_linux-lv_root ro crashkernel=auto rd.luks.uuid=luks-f5d241cd-4f2a-469f-8765-a26f36492ccb rd.lvm.lv=vg_oracle_linux/lv_root rd.lvm.lv=vg_oracle_linux/lv_swap rhgb quiet LANG=en_US.UTF-8

                    initrdefi /initramfs-4.14.35-1818.3.3.el7uek.x86_64.img

            }

            menuentry 'Oracle Linux Server 7.6, with Unbreakable Enterprise Kernel 4.14.35-1902.3.1.el7uek.x86_64' --class oracle --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.14.35-1818.3.3.el7uek.x86_64-advanced-42f19163-ae4c-422e-8e8e-2564f8c28681' {

                    load_video

                    set gfxpayload=keep

                    insmod gzio

                    insmod part_gpt

                    insmod ext2

                    if [ x$feature_platform_search_hint = xy ]; then

                      search --no-floppy --fs-uuid --set=root  a41575ba-19e7-4729-8fff-769de4c6333f

                    else

                      search --no-floppy --fs-uuid --set=root a41575ba-19e7-4729-8fff-769de4c6333f

                    fi

                    linuxefi /vmlinuz-4.14.35-1902.3.1.el7uek.x86_64 root=/dev/mapper/vg_oracle_linux-lv_root ro crashkernel=auto rd.luks.uuid=luks-f5d241cd-4f2a-469f-8765-a26f36492ccb rd.lvm.lv=vg_oracle_linux/lv_root rd.lvm.lv=vg_oracle_linux/lv_swap rhgb quiet LANG=en_US.UTF-8

                    initrdefi /initramfs-4.14.35-1902.3.1.el7uek.x86_64.img

            }

            Personally I'm not familiar enough with this to see a problem here. Are there any other relevant parameters I should compare?