-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add auto-unlocking support #27
base: master
Are you sure you want to change the base?
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.