Conversation
The header linux/nvme.h was replaced by linux/nvme_ioctl.h in kernel versions greater than 4.4: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9d99a8dda154 The needed structs and opcodes are copied into a new header file from nvme.h. See also: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a9cf8284b45110a4d98aea180a89c857e53bf850 https://www.bountysource.com/issues/29775575-linux-nvme-h-has-been-renamed-in-linux-4-4
|
Brilliant! |
|
Does the autounlock work with TPM1.2 based systems as well? |
I think the original author is dead jim, If you could step in, that would be amazing. |
|
Shameless plug; I have written a Go library to replace having to use sedutil - https://github.com/bluecmd/go-tcg-storage - and I am implementing a PBA based on u-root at my place of work (https://github.com/elastx/elx-pba). Happy to accept contributions there if you want! We will use machine UUID to unlock disks, but happy to include support for TPMs etc if somebody else wants to write and maintain it. We currently use I am available at the Open Source Firmware Slack (https://slack.osfw.dev/) if anyone wants to discuss this more! |
|
Please consider to add auto-unlock feature. |
|
+1 For the feature 🙏 |
I would very much like you to consider merging this, as non-interactive authentication is IMHO the one killer feature still missing from sedutil PBA. The original PR, aimed at original DTA sedutil, can be found here: Drive-Trust-Alliance#86.
If the original author is no longer around or not interested in adapting this to the current master, I am willing to step in.
Original PR description follows.
This will allow the SSD to be unlocked with any combination of:
This gives much more flexibility in unlocking the SSD and allows the actual SSD encryption password to be completely random (which is more secure) while still allowing an easy way to unlock the SSD as long as a second factor is present and conditions are met.