Arch Linux User Repository

To build this package you need to install one of the following:
linux-headers: if you are using Arch's kernel
linux-lts-headers: if you are using Arch's LTS kernel

Let's give it some time and see what happens. If the fork starts to get new code and stable releases then I suppose a change might be in order, until then lets wait and see.

Maybe it's time to change the git repo url?
https://github.com/Drive-Trust-Alliance/sedutil/pull/56#issuecomment-302948612

Unable to install on 32-bit system. Please fix.

Error: can not find the makefile for configuration 'Release_i686' in project LinuxPBA
See 'make help' for details.

$ make help
This makefile supports the following configurations:
Debug Release Release_x86_64 Debug_x86_64

Works fine for me.

You'll have to provide more context, otherwise with just that message it's not going to be easy to tell what the problem may be.

This isn't installing with a DtaDevLinuxNvme.h error: linux/nvme.h no such file error

I forgot to mention before, there is a trick to creating the PBA entry when using efistub, the disk must be locked when you call efibootmgr, otherwise it will not know the uuid of the partition and obviously it will fail to start the PBA image using efistub. The trick here is to use a system on a usb drive to create the PBA uefi entry while the disk is locked.

Regarding the bios changing the order of the entries or deleting entries, I believe that is bios/fw dependent, I don't have any problems with my laptop (Lenovo E560) but there are bug reports about that in the sedutil bug tracker, see [1-2].

[1] https://github.com/Drive-Trust-Alliance/sedutil/issues/66
[2] https://github.com/Drive-Trust-Alliance/sedutil/issues/27

Yes, it makes perfectly sense being able to move the device to an older machine, good point. Completely forgot about EFI stub, I will have a look at what I can achieve with secure boot.

By the way, did you experience any issue with EFI entries? If I create an EFI entry and then I lock the SSD turning the power off, then the entry disappears, probably because the BIOS can't find the partition anymore (but the EFI entry still exists in efibootmgr). After unlocking the SSD through the shadow MBR I expected the BIOS to show the EFI entry once again, but it doesn't happen on my Dell XPS 13 9343 BIOS A09. Am I the only one with this issue? Currently I'm booting using the default entry only.

For me it makes sense to support both bios and uefi because I still have machines that are bios only and those can be used in case my main machine breaks down (this has been useful to me in a very recent past). There might also be interest for people with older machines that don't support aes-ni but still want to use encryption, by using a sed that comes without performance penalty.

Regarding secure boot, I haven't looked much into it yet. You can use more than one method of whitelisting your bootloader, from what I've seen you can use either hashes or signatures so I'd like to give the alternatives a try myself before releasing anything half baked and can provide some pointers for other people.

Cryptboot seems like a nice helper to deal with secure boot, I haven't taken too long looking at it but it seems a bit geared towards grub, I'd rather have the PBA image be as generic as possible, what people do/use after the disk is unlocked should not be my concern (less risk of bugs or borking things).

There is also the fact that if you are using a uefi machine you don't need a bootloader, you can boot the kernel directly[1], which I have been doing and so far it works well. In this case I suppose you only need to sign your kernel image before you create the PBA image or include the hash in the whilelist, but like I said before I haven't tested it yet.

[1] https://wiki.archlinux.org/index.php/EFISTUB

That makes sense, I thought about creating an hybrid image but from my point of view it wasn't worth the additional effort because we really want secure boot support anyway, possibly using something like cryptboot[1] to sign the image.
I still didn't implement secure boot in my helper because I still have to figure out the best way to accomplish it, especially if I really want to use something like cryptboot. Any idea?

[1]https://github.com/xmikos/cryptboot

@darkbasic
I'll include your first patch to unbreak building (again) until upstream fixes the problem[1]. In Arch we don't have linux versions below 4.4 so we don't really need the conditionals but I'll include it as is as most probably that is what upstream will use.

Regarding the uefi image creation script, I have been working on a new script which will create hybrid images (bios+uefi) and I'm planning to move away from separate scripts for bios and uefi which means I will not use your script, but I thank you for taking the time to implement and test it, I can serve as an alternative/reference for other people.

I'm also planning to move the sources to github, I have been contacted by email regarding that and I'll probably do it after upstream releases a new version, for now I'll just push my changes and fix building.

[1] https://github.com/Drive-Trust-Alliance/sedutil/pull/56#issuecomment-263739472