search

Drive-Trust-Alliance / sedutil

DTA sedutil Self encrypting drive software
610 stars 236 forks source link

Cross platform issues #395

Open FredKellerman opened 2 years ago

FredKellerman commented 2 years ago

Using the Linux 64-bit and the Windows executables from the master branch, release 1.20 seems to have a cross platform issue. I seem to be able to initialize and unlock etc. OK if using from 1 of either host OS. But if I set the password from say a Linux 64-bit host and then try to unlock the same drive from Windows 11, it errors with not authorized. Returning to the original host that setup the drive works again without issue. Just as a test I used the -n option to bypass the hash and then either host OS can unlock the drive.

Is this expected behavior or a known limitation?

JaBoMa commented 2 years ago

Refer to the following threads (just as the examples; both issues are closed): https://github.com/Drive-Trust-Alliance/sedutil/issues/377 https://github.com/Drive-Trust-Alliance/sedutil/issues/359 Read e.g. "Encrypting your Drive" under "Wiki" tab (https://github.com/Drive-Trust-Alliance/sedutil/wiki/Encrypting-your-drive), especially that "ALL steps below should be run on the RESCUE SYSTEM". Yes, the problem of different way of password hashing between Linux and Windows is known.

r0m30 commented 2 years ago

It depends..... USB attached drives are probably not compatible, this is because of OS implementation differences. NVMe drives are currently not compatible because Windows implemented NVMe as scsi pass-thru and the real serial number is not accessible via this implementation. They have added a system call to get the real serial number (about 21H1), I've written the code to implement this call but haven't had time to develop the documentation and create a legacy windows distribution.

FredKellerman commented 2 years ago

It depends..... USB attached drives are probably not compatible, this is because of OS implementation differences. NVMe drives are currently not compatible because Windows implemented NVMe as scsi pass-thru and the real serial number is not accessible via this implementation. They have added a system call to get the real serial number (about 21H1), I've written the code to implement this call but haven't had time to develop the documentation and create a legacy windows distribution.

Then that is why. My context was NVME. Its not that uncommon to run multiple OSs, Windows & Linux on the same machine. Thanks for all your labors on this project!

JaBoMa commented 2 years ago

You are right, it is not that uncommon. But if the Opal SSD is the system booting, then its Shadow PBA partition contains Linux. And that's why you are advised to encrypt your disk using the Rescue System (Linux as well).

FredKellerman commented 2 years ago

You are right, it is not that uncommon. But if the Opal SSD is the system booting, then its Shadow PBA partition contains Linux. And that's why you are advised to encrypt your disk using the Rescue System (Linux as well).

Thank you, the Rescue System comes with some restrictions on BIOS modes that is one reason it is not ideal for me. Also, for a laptop the most power miserly NVMe drives right now are made by Hynix which are not SED capable. For me given that, I prefer to use Windows and BitLocker for the Hynix SSD and leave a small Luks partition containing a lightweight Linux that can also use sedutil-cli. I was a little surprised to find out that the hash was not the same when trying to unlock a second NVMe drive which contains ext4 partitions that can be also be mounted in Hyper-V VMs as a raw disk or mounted by booting into Linux without a VM. The latter is needed once in a while for certain applications that need all the RAM it can get. Don't get me wrong, very happy with what it is now. Others use PCs like this I'm sure but probably not a lot of users. Thanks again!