-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Windows S3 sleep driver #1
Comments
@CuzImBAerle Yes at this point I think just going ahead with an open source release is the best way forward, so I will probably do that soon. I will have to investigate the license requirements of the sample material it is built from, which appears to be MS LPL. Unfortunately at the moment it would require compiling from source to use. I don't have a driver debugging setup or a machine with a non-boot NVMe drive, so even getting it as far as it is was basically russian roulette! |
So not really had time to tidy it up or investigate licenses etc, but I've made the repo public here https://github.com/lukefor/SEDSleep On the bright side it's been absolutely rock solid for me for months - zero failed sleeps, zero BSODs, etc. Not bad for a first foray into debugger-less driver development! |
@lukefor what does this fork do that the standard Sedutil does not? (not including your separate NVME driver). Are you booting on NVME via the linux PBA image, booting to Windows 10, then able to sleep in Windows 10? |
Yes, exactly that. Being able to resume from sleep is the key feature, with standard sedutil you can only hibernate |
So, your fork has two purposes: (1) to lock and unlock non-boot NVME drives in Windows 10, and (2) to boot to NVME with the Linux PBA to Windows 10? And, your Windows 10 driver is totally separate, but enables wake from sleep with a sedutil locked NVME drive? |
Yes, and also to prepare a Windows boot drive for sedutil without involving Linux
Standard sedutil can do that
That's right yeah |
Can you explain how to do this with your repo? This sounds terrific! |
Thanks @lukefor, but I was wondering if you could give some hopefully quick advice. Hopefully you can guide me down the rabbit hole! So far, I've built sedutil-windows_sleep, but I can't get the CLI to create a send9.bin. It's only created a send3.bin, send5.bin, send7.bin. I think this might be because "--setlockingrange 0 rw password \.\PhysicalDrive0" substituted with my password doesn't finish correctly with "One or more header fields have 0 length, EndSession Failed" I booted into ChubbyAnt's rescue environment and can run that command fine. It would be something great to have working sleep! |
It might be due to a driver issue - the windows NVMe unlocking code uses SCSI emulation, whereas the Linux/rescue NVMe code uses native NVMe. For me it is working on the Microsoft NVMe driver, and I seem to recall it failed on other drivers. Also possibly the SCSI emulation approach only works on certain drives - the drive I am using is the Samsung 970 Evo Plus. (Still not a single BSOD or failed sleep/resume!) Failing that you could try integrating the hack (dd60185) into whatever the latest fork is for windows nvme |
Thank you for the reply! This would be so great that I can't believe the main sedutil branch doesn't list it as an option on their page. Maybe these commands can't complete since I've installed the ChubbyAnt fork using the rescue environment following the instructions at sedutil.com? I'm a noob with a lot of this. I haven't used VB since 2008. I'm unsure know how to create a bootable USB to install your fork through the rescue environment. I have a 970 Pro and I had the Samsung NVMe driver installed. I uninstalled and now have the default Windows driver listed in Device Manager > Storage controllers. Still no joy. Same "One or more header fields have 0 length" error in command prompt using CLI for I don't expect you to support me getting this running, but I want you to know your reply was very appreciated and I hope this project goes further! |
@lukefor could you link your already built pba rescue image for your "windows_sleep" branch so I could try it? I can't build it with Ubuntu 20.04, but I can build ChubbyAnt's RESCUE64-1.15.1-46-g7bb7c31.img.gz newer image fine. I'm getting an error during ./buildpbaroot with your repo because it uses an older version of gnulib m4 that I can't patch. The error comes from m4-1.4.18: "freadahead.c:92:3: error: #error "Please port gnulib freadahead.c to your platform! Look at the definition of fflush, fread, ungetc on your system, then report this to bug-gnulib."" |
Maybe your issue is to do with the SHA-512 change, I'm still using the SHA-1 code here. Probably no issue on the driver end, but I suspect you would need to integrate the bin output hack to the ChubbyAnt fork so that the correct hashed password etc is used, if you have setup your drive using SHA-512 For PBA if I remember correctly I am using the one from https://github.com/ladar/sedutil (SHA1 edition), before that I used the original DTA PBA. Never needed to build a custom one |
I removed ChubbyAnt's PBA and I'm now using ladar's SHA1 build to see if it made any difference. Integrating the SHA-512 hack was over my head. Whether I use your windows_sleep cli or windows_nvme cli, I still get "NOT_AUTHORIZED" with the "--setlockingrange 0" command. I'm using my PBA password exactly. I can't extract the correct .bin files no matter what I do for use with SEDSleep. I know you said this was in a "working for you status." Would you take a donation if you can get it in a "working for me" status? I think I've exhausted all options. |
Is there any fork where you are able to run the unlocking commands from within windows? It sounds like there is something different about your drive or firmware that would be over my head to solve One thing that comes to mind is maybe your drive does not handle being unlocked while it is already unlocked. You may be able to boot windows from another disk (without unlocking your nvme drive) and run sedutil from there And this may be stating the obvious, but did you re setup your drive with SHA1? I believe it requires reconfiguring from scratch or at least changing the key somehow |
@lukefor, thank you for the guidance! It gives me that motivation to try just about everything to get this to work. 👍 I used ladar's latest SHA1 build (RESCUE64-1.16.0-SHA1.img.gz) and I booted a USB with Hiren's BootCD PE. I was able to extract all necessary send files from the NVMe drive, xxd to .h, edit variables, and build the SEDSleep driver in VB!!! I'm unsure whether to install the driver under Device Manager > "Disk Drives" or "Storage Controllers" for my 970 Pro. Either way I get an error "The folder you specified doesn't contain a compatible software driver for your device. If the folder contains a driver, make sure it is designed to work with Windows for x64-based systems." I think this could be because either I'm trying to install it incorrectly, or I built it using the Win32 platform option in VB. (I had to disable Wpp Tracing for it work.) I can't build using x64 platform. I get the error "tracewpp : error wpp: Unable to open file 'trace.h': CreateFile error 2." That's even with WPP Tracing disabled. Thank you yet again for your time. |
If I remember correctly to install you just right click > install the .inf file You definitely need to get it built as x64 for it to work, not sure about that error |
Have you got the WDK installed as well as visual studio? |
I sure do (or rather I sure did). I went ahead and did the right click install for the win32 inf I could build. Windows wouldn't boot past the loading screen. Had to restore an image. |
A second windows installation really helps for that, I was having to regularly boot into a second install and edit the registry in the main install to disable the driver to get it booting again |
Does it install as a "Disk Drive" or "Storage Controller" driver? That way I know which to disable if I keep on tinkering! |
It's a storage filter driver so I don't think it will show up in device manager etc, you'll find it in the registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SEDSleep or in the services tab of apps like process hacker |
@lukefor thank you for your work on this project and contributing to the git community! I am now successfully able to use sleep in Windows 10 with @ladar's latest SHA1 1.16 build! I was able to successfully create and install the SEDSleep.inf driver. I had to set VB's Project > SEDSleep Properties > All Configurations > Wpp Tracing > General > Run Wpp Tracing > No. Then I could compile the x64 driver with the send files I extracted through Hiren's PE! Each time I boot Windows, I do have to select F8 for advanced boot options and then the # 7 to disable driver signing. I think this is because I don't have an EV certificate to sign the driver. Honestly though, this is is a small "inconvenience" to be able to use OPAL hardware encryption with S3 sleep. I can't thank you enough. This is awesome and I hope other people can get it to work if they think the security considerations justify being able to use sleep! (For anyone reading, please feel free to reach out to me through Github if you think I could assist you with this process). |
(Writing this here rather than the main repo because of Github's ridiculous GDPR policy.)
I've written a driver implementing S3 sleep for sedutil on Windows. It's currently at a stage of 'works for me', as in the absolute bare minimum - it supports NVMe only and hard codes the unlocking scsi commands.
I'm in two minds whether to release it as open source - it is of limited usefulness in its current form, the code quality is very much unfinished, and it needs signed with an EV cert for the average user.
This post is basically putting the feelers out - is there enough interest for me to finish it off and run it as a donationware* model? Or, do the 'drive trust alliance' want to sponsor an EV cert?
Blame Microsoft for me even having to ask these questions - if only their driver signing requirements weren't such a challenge for open source projects.
*Something along the lines of FOSS licensed, with a payment/donation to receive a signed binary
The text was updated successfully, but these errors were encountered: