search

ChubbyAnt / sedutil

SEDutil: For Intel and AMD Ryzen Systems
https://sedutil.com
92 stars 22 forks source link

sedutil-cli@Win10 + Ryzen SATA: freeze, 5 minutes/command, detection-issues #2

Open aj-git opened 5 years ago

aj-git commented 5 years ago

The Windows executable (sedutil-cli.exe) v1.15.1-9 doesn't work with SATA-Drives (it behaves the same way like the original DTA v1.15.1 release). Here you can find my original report describing the issue: https://github.com/Drive-Trust-Alliance/sedutil/issues/242 Just wanted to leave a note after some short tests. I'm still hoping someone is able to fix it.

Perhaps the Default "Microsoft SATA AHCI Controller" Driver has issues or requires "special treatment", but there must exist a way: Micron MSECLI works flawless (is able to detect OPAL-drives, their state and issue a PSID-revert) with drives connected to the Ryzen onboard SATA Controller.

ChubbyAnt commented 5 years ago

We have not experienced this issue. What hardware are you using? Have you tried the Windows compiled binary from the windows_nvme or windows_sleep branch of this repo:

https://github.com/lukefor/sedutil/tree/windows_sleep

@lukefor made substantial changes to the Windows side of the code and has sleep working in Windows with a self-baked Windows driver:

https://github.com/lukefor/sedutil/issues/1

aj-git commented 5 years ago

Thanks for directing me to the lukefor repo! Sadly I can't find any compiled windows executables - any chance you have a compiled sedutil-cli.exe?

We have not experienced this issue. What hardware are you using?

If you attach disks (Opal or non-Opal) to a Ryzen onboard SATA-Controller --scan and --query are working correctly (using sedutil-cli.exe @Win10)?

hmm, I don't think there is anything special: Mainboard: ASUS Prime X470-Pro (x470 Chipset, BIOS: v4602) CPU: AMD Ryzen 7 2700X RAM: 64GB DDR4 Graphics: Sapphire Nitro+ Radeon RX 570 8GD5 Storage (onboard SATA): 1x Crucial MX500 500GB (FW: M3CR023, Opal/eDrive not provisioned/enabled) for OS, 2x Intel SSD DC S3500 600GB (FW: D2010370, not Opal/eDrive capable) for data Intel Wireless-AC 9260 (for WLAN & Bluetooth connectivity) OS: Win10 v1803 x64

Any idea what could cause my problems? ...or what I should test?

ChubbyAnt commented 5 years ago

We compiled the @lukefor Windows executables, but do not have them anymore. Do you want to try to compile them? Here's how:

  1. Install Microsoft Visual Studio 2015
  2. Add C++ tools to VS2015
  3. In Windows Powershell, VIA Powershell: set-executionpolicy unrestricted -> change back when you are done with these steps! set-executionpolicy RemoteSigned Verify policy reset: get-executionpolicy
  4. Via an elevated command prompt: c:\windows\syswow64\WindowsPowerShell\v1.0\powershell.exe -command set-executionpolicy -Scope CurrentUser unrestricted -> change back when you are done with these steps! c:\windows\syswow64\WindowsPowerShell\v1.0\powershell.exe -command set-executionpolicy -Scope CurrentUser Restricted Verify policy reset: c:\windows\syswow64\WindowsPowerShell\v1.0\powershell.exe -command get-executionpolicy
  5. Open VS2015
  6. Open -> Project/Solution -> sedutil/windows/CLI/CLI.sln
  7. Project -> Retarget Solution -> 8.1
  8. Build -> Configuration Manager -> Configuration -> Release
  9. Build -> Build Solution This should build the windows executable sedutil.exe Make sure to change the policies back in 3 and 4 above.
aj-git commented 5 years ago

Found the time to give it a try, but sadly my self-compiled executable does not change anything. :-(

Long story: Could not successfully compile using VisualStudio2015. It reported missing "v142-Buildtools" and after lowering the Plattformtoolset to v140 (= VisualStudio2015?) it gave me 27 errors complaining about undeclared identifier around "PSTORAGE_PROTOCOL_SPECIFIC_DATA" and "PSTORAGE_PROTOCOL_DATA_DESCRIPTOR". I gave up, restored an old vm-snapshot and started over with VisualStudio2019 (and Workload "Windows\Desktop development with C++"): finally got the executable (using Windows SDK-Version = 10 and Plattformtoolset = v142). But the joy didn't last long because it behaves exactly like the DTA executable (sedutil v1.15.1 release): for example a --query on a non-opal drive runs exactly 5 minutes until it reports "0000 Invalid or unsupported disk"

Anyway, thank you very much for your guide! Wouldn't have kept trying without your help! May I ask what step 3 and 4 are good for? (I guess it is for the "GitVersion.ps1" in the source-code? Looks like the powershell-script didn't work for me because I had no GIT Software installed...probably the reason why my executable reports version "sedutil v1" using the "--help" switch?)

By the way: Do you know why the "-v" or "-vvvvv" switch doesn't really change anything about sedutil-cli's output? To me it looks like the switch doesn't do anything (= is defect)!? I would really like to see some debug/info message to get an idea what sedutil-cli is doing five minutes long with each drive it tries to access. ( For me it looks like there are debug messages in the source code, but I don't see them when I use sedutil-cli - even when I compile a "debug" version.)

ChubbyAnt commented 5 years ago

Sorry to hear you are not making overall progress.

By the way: Do you know why the "-v" or "-vvvvv" switch doesn't really change anything about sedutil-cli's output? To me it looks like the switch doesn't do anything (= is defect)!? I would really like to see some debug/info message to get an idea what sedutil-cli is doing five minutes long with each drive it tries to access. ( For me it looks like there are debug messages in the source code, but I don't see them when I use sedutil-cli - even when I compile a "debug" version.)

The verbose logging switch does not do anything "more" if the build already has verbose logging enables by default.

capitaltpt commented 4 years ago

I'm experiencing the same issue as @aj-git Scans and queries take 5 minutes to return information and it shows that none of the my drives are Opal compliant despite everything working flawlessly in the preboot image. This is occurring on both the 1.15.1-9 and 1.15.1-44 windows executable.

Mainboard: ASUS Zenith Extreme (x399 Chipset, BIOS: v2001) CPU: AMD Ryzen Threadripper 1920X RAM: 32GB DDR4 Graphics: EVGA 1080Ti Storage (onboard SATA): Samsung 960 Pro 512GB (FW: 4B6QCXP7), Samsung 850 EVO 500 GB (FW: EMT02B6Q), Seagate ST6000NM0044 6TB OS: Win10 v19041

MathewCNichols commented 3 years ago

I'm experiencing the same issue as @aj-git Scans and queries take 5 minutes to return information and it shows that none of the my drives are Opal compliant despite everything working flawlessly in the preboot image. This is occurring on both the 1.15.1-9 and 1.15.1-44 windows executable.

Mainboard: ASUS Zenith Extreme (x399 Chipset, BIOS: v2001) CPU: AMD Ryzen Threadripper 1920X RAM: 32GB DDR4 Graphics: EVGA 1080Ti Storage (onboard SATA): Samsung 960 Pro 512GB (FW: 4B6QCXP7), Samsung 850 EVO 500 GB (FW: EMT02B6Q), Seagate ST6000NM0044 6TB OS: Win10 v19041

The ChubbyAnt fork executable reports "No" for me too. However, the compiled lukefor forks both report a "2."

MathewCNichols commented 3 years ago

Thanks for directing me to the lukefor repo! Sadly I can't find any compiled windows executables - any chance you have a compiled sedutil-cli.exe?

We have not experienced this issue. What hardware are you using?

If you attach disks (Opal or non-Opal) to a Ryzen onboard SATA-Controller --scan and --query are working correctly (using sedutil-cli.exe @win10)?

hmm, I don't think there is anything special: Mainboard: ASUS Prime X470-Pro (x470 Chipset, BIOS: v4602) CPU: AMD Ryzen 7 2700X RAM: 64GB DDR4 Graphics: Sapphire Nitro+ Radeon RX 570 8GD5 Storage (onboard SATA): 1x Crucial MX500 500GB (FW: M3CR023, Opal/eDrive not provisioned/enabled) for OS, 2x Intel SSD DC S3500 600GB (FW: D2010370, not Opal/eDrive capable) for data Intel Wireless-AC 9260 (for WLAN & Bluetooth connectivity) OS: Win10 v1803 x64

Any idea what could cause my problems? ...or what I should test?

Thanks for directing me to the lukefor repo! Sadly I can't find any compiled windows executables - any chance you have a compiled sedutil-cli.exe?

We have not experienced this issue. What hardware are you using?

If you attach disks (Opal or non-Opal) to a Ryzen onboard SATA-Controller --scan and --query are working correctly (using sedutil-cli.exe @win10)?

hmm, I don't think there is anything special: Mainboard: ASUS Prime X470-Pro (x470 Chipset, BIOS: v4602) CPU: AMD Ryzen 7 2700X RAM: 64GB DDR4 Graphics: Sapphire Nitro+ Radeon RX 570 8GD5 Storage (onboard SATA): 1x Crucial MX500 500GB (FW: M3CR023, Opal/eDrive not provisioned/enabled) for OS, 2x Intel SSD DC S3500 600GB (FW: D2010370, not Opal/eDrive capable) for data Intel Wireless-AC 9260 (for WLAN & Bluetooth connectivity) OS: Win10 v1803 x64

Any idea what could cause my problems? ...or what I should test?

Here are compiled @lukefor executables if anyone stumbles across this thread and wants to try them:

Even though @lukefor executables correctly report "2" for OPAL status, I haven't been able to pull information from my PBA since I get "method status code NOT_AUTHORIZED" and "One or more header fields have 0 length."

Sed-Research commented 3 years ago

@MathewCNichols both those google drive files for the windows compiled lukefor executables have the same MD5 meaning they are both what I believe is the sedutil_windows_sleep executable. They required me downloading and placing vcruntime140_1.dll in the same directory however it did end up working and identifying NVME opal drives over pci-e in Windows.

Oom-is sedutil fork works well for me too for nvme over pci-e in windows but it has the SHA512 implementation (beware: different forks have different SHA512 password hashing implementations such that based on my testing oom-is and chubbyant forks were not cross compatible with ladar's forks - unless you are feeding the password directly to the drive without hashing it using -n switch).

As a general workaround to those who need NVME support in Windows for internally installed drives (and thunderbolt enclosures which also use pci-e bus), you can use preboot authentication to unlock the drive before booting into Windows or, something that I have tested with usb attached drives but assume it will work with PCI-e connected drives too, is attaching the drive to a virtual machine (vmware player worked for me) and unlocking the drive through linux or PBA then relinquishing the drive back to the windows host machine.

More on nvme opal drive support over USB in windows here:

https://github.com/Drive-Trust-Alliance/sedutil/issues/115#issuecomment-751353033