UEFI x64 PBA Rebooting after entering password

[jjfraczek]

Hello, thanks for making this!

I'm attempting to use the UEFI64_Release.img PBA that's posted on the ArchLinux wiki, but upon entering the password, my system instantly reboots and I do not gain entry to my nvme. This occurs during testing and with live usage, had to rescue my system. I have a ArchLinux x64 UEFI w/a Samsung 960 EVO 250GB drive, using an ASUS Z270 motherboard w/TPM.

Would building a custom image help my case? It mentions "mklinuxpba-efi", but no idea.

[kylemanna]

Currently there isn't support for NVMe drives in the default PBA images.

There is extensive discussion @ #120 and I have some pre-built images as well source for you to build your own at https://github.com/kylemanna/sedutil/releases/tag/1.12-nvmepba-docker

It's tested and works on Arch Linux/Win10 Dual Boot + Dell Precision 5510 + Samsung 960 EVO 1TB.

[jjfraczek]

Thanks. I just tried booting this off my flash drive.

ERR: method status code INVALID_PARAMETER
ERR: Session start failed

• 22:59:46.474 ERR: One of more header fields have 0 length
• 22:59:46.474 ERR : EndSession Failed
• 22:59:46.747 ERR : Unlock failed - unable to set LockingRange 0 RM.

I'm just trying to test the PBA prior to attempting to use it.

For what it's worth, I took note of issue @ #73 and just "bit the bullet" and installed it (even though the test failed). Still didn't work in an actual install on the drive. First time around I got an error, but it was too fast to see. Ended up having to boot the rescue USB. Unlocked the drive, but had to rebuild my GRUB boot partition.

Thanks

[r0m30]

This should be resolved in the new v1.15 code.

[rinc3w1nd]

Unfortunately, the issue of a reboot remains even if the code for access to NVMe drives is resolved. The drive remaining unlocked after warm-reboot is a security flaw which some manufacturers - such as HP - have resolved in their BIOS. Without a proper chainload of the OS on drive following unlock it PBA computers which rightly relock the drive on reboot will fail to ever make past the PBA.

This relock on reboot is a necessary step to preventing alt-OS boot attacks against an unattended machine left in a running state.

[r0m30]

True, if the vendor chooses to power cycle the drive on a reboot then the current PBA design will not work. UEFI coding isn't something I'm familiar with but I believe a UEFI module is what would be required.

[rinc3w1nd]

Could this instead be done by loading grub or syslinux on the drive MBR and utilizing a initramfs to execute sedutil instead of full boot img? It strikes me that we may not need full UEFI implementation if we can use what is already there...

[r0m30]

@daijizai I'm not sure I understand what you are saying here. The current UEFI PBA is currently an initramfs loaded by Syslinux that executes linuxpba. linuxpba is a customized version of sedutil.

[rinc3w1nd]

Apologies, I didnt make this clear to what I was referring. With a OPAL spec drive the drive MBR loads your initramfs... What I meant was, that instead of doing this we load a bootloader, like grub, where the OS kernel has also been pushed to the mbr in drive, and load sedutil as an initrd image to the kernel and then continue the boot process. I understand that the mbr containing the kernel will disappear logically, but the kernel would have already been loaded into ram, and it may then be able to find its root as the partition structure will have become unlocked.

I may be completely off... not intimately familiar with the kernel load process at this level...

[cristim]

I think going forward the best way to achieve this is to implement some OPAL support in grub, which would perform the unlocking and chainload the OS from the unlocked drive.

The PBA would just contain Grub configured to unlock and chainload the OS from the same drive.

[rinc3w1nd]

I have a feature request in in grub's bug report. Perhaps you can add a word of support? http://savannah.gnu.org/bugs/?51418 I agree that would be ideal, but I'm holding out hope for a more near term solution.

[cristim]

Thanks @daijizai, I'll show my support there.

In the meantime you can try this alternative PBA which does kexec to load your Kernel, hopefully it works for you: https://github.com/gebart/opal-kexec-pba

Disclaimer: I didn't test it, YMMV.

[r0m30]

Our newest PBA also supports NVMe. You can get it here

[rinc3w1nd]

Excited to test this, and do some digging. Unfortunately my gear for this project is not traveling with me to BlackHat/DEFCON so I will test on return, dig in to this method, and see what I can contribute. Thanks!