Asking kindly for joint effort to improve sedutil: S3 Sleep and more.

[mabachel]

Hello @ladar while scrolling through your commits I found some great improvements over DTA's sedutil. Are you willing to adapt some of them to https://github.com/ChubbyAnt/sedutil/

It got recently updated to compile against glibc > 2.28 (updated LTS buildroot, thanks to @oom-is).

I would love to see a resurrection of sedutil development with joint efforts of @ladar, @oom-is @ChubbyAnt, @badicsalex, @DarkSpyro003, @ckamm and more.

See also: ChubbyAnt#6 and https://sedutil.com/

[oom-is]

I think this is a worthwhile endeavor and I will be happy that any work I'm doing gets re-used/incorporated.

To be clear, though, there are different goals and different testing environments. I am curating a fork because I have a specific set of requirements that boil down to:

• Any feature that is fully supported in my tree has to work the same on Windows and Linux (and yes, that means at some point I need to fix --verbose logging on Windows and extend -s secure mode to Windows, since the former is an existing issue and the latter is a feature I Want.)
• CLI utils/Rescue have to support some older crappy monitors; support for HiDPI/4k monitors is "useful but not immediately required".
  ==>If default video mode is to be e.g. 720p then that needs to be implemented in a way that still Just Works on Very Old Laptops (because people still use those, even with newer SED SSDs.)
• I have a variety of SATA SEDs (both 2.5" and M.2, and both SSD and "spinning rust") that I am currently using for testing/validation; I haven't yet started doing NVMe testing because the environment I'm targeting doesn't use those drives yet.
• I do not expect to support S3 sleep in my tree unless and until someone convinces me that it's actually needed and secure. [Hibernation works for my use cases, and I really really prefer getting a passphrase prompt when "waking up".] (see also discussion: DTA#8, DTA#90 ) -- That said, I could live with a common tree that defaulted to "S3 sleep enabled" as long as there was a compile-time flag to completely disable it.
• The current/next areas I'm working are a script that builds a "true UEFI" bootable ISO for CD-R version of Rescue64, documenting setup of a non-admin "user1" with only drive unlock ability, and then a curses-based menu system to automate common tasks from the Rescue img/ISO.

[ladar]

I'd be happy to incorporate changes from other forks, but someone else will have to generate a pull request. I can then function as a "reviewer." Unlike @oom-is though, I don't have access to a wide range of systems/drives to test against, so I can't find/fix issues that don't show up on my system.

Rather, what I focused on when I created my fork was improving the experience on a 4K notebook screen. Without my changes, the sedutils recovery image, and PBA text was so tiny, I had to get within an inch of the screen, and even then it was struggle. And as someone with an infosec/crypto background, I also felt it was important to update the code with a variety of misc security improvements. Specifically switching to SHA-512, while adding additional hash rounds, for better brute force protection, since SHA-1 has had issues for awhile now. I also wanted to limit the number of attempts per boot.

In terms of my priorities, I'd like to get S3 sleep working properly. Right now, if my notebook goes to sleep, it will hang when it wakes back up. But if sleep support requires giving the kernel access to the device password/encryption key, then I'll pass, as it defeats on of the big advantages to using hardware crypto (along with performance). Perhaps using a unique key per boot could work, that way if malware steals it, the attacker won't be able to use to unlock the device later.

Linux chain loading is the other priority for me, as it would cut each boot by ~30 seconds.

I'd place adding a terminal interface, based on curses, in the important category, as it would make sedutil far more user friendly, and easy to setup. The current process is well beyond the capabilities of anyone without software development and system admin skills. And a big chunk of people who need this the most (reporters, activists, political leaders, etc, don't have those skills.

Note the use of SHA-1 isn't necessarily a problem. It depends a lot on what the device does with the value it's given.