Sleep support

[lulkipvx]

Are there any plans for sedutil to support HDD sleep? This is the single most feature that has got me disabling sedutil currently.

[Venemo]

@ScottyBauer Is there a way I can test it? I've never compiled a kernel before but I'm willing to give it a try now!

[ScottyBauer]

Sure its pretty easy, I guess. git clone https://kernel.googlesource.com/pub/scm/linux/kernel/git/axboe/linux-block.git cd linux-block git checkout origin/for-next wget "https://plzdonthack.me/0001-block-sed-opal-Set-MBRDone-on-S3-resume-path-if-TPER.patch" git am 0001-block-sed-opal-Set-MBRDone-on-S3-resume-path-if-TPER.patch cp /boot/config-`uname -r` .config yes "" | make oldconfig

From here open up your .config in your editor and verify that CONFIG_BLK_SED_OPAL=y exists, if not append it anywhere.

make -j (nuber of processors you have here without parens) make modules_install install reboot now

[Venemo]

@ScottyBauer I decided to create a patched version of the Fedora kernel. (I'm running Fedora so it's a bit easier to deal with that.) At the first try everything seems to be working correctly!

[Venemo]

@ScottyBauer Is there a chance that your patch gets into 4.13?

[ScottyBauer]

No 4.13 was just released on Sunday, I think. It will for sure be in 4.14 but I'll see if I can get it back ported to 4.11 (or what ever version hey picked up for stable) since it's a trivial patch and doesn't touch any subsystem but mine, so it will just need to be applied by GKH.

[Venemo]

@ScottyBauer I filed a request for the Fedora kernel team to include your patch in their kernel: https://bugzilla.redhat.com/show_bug.cgi?id=1489843 ― I hope this is okay with you.

[ScottyBauer]

No problem I got contacted by RHEL already, I told them to take this patch too. The more people pointing it out the better.

[zbraniecki]

New user of OPAL2.0 here, just hit this issue. Would it be possible to document the process of adding resume support on your wiki? Going through threads trying to capture the dynamically changing steps is daunting :)

[Venemo]

@zbraniecki It's not made as a user-friendly solution yet, unfortunately. Basically, you have to run a small command-line app that calls the specific system call with the correct password. And you have to use a recent enough kernel.

[zbraniecki]

@Venemo this sounds like a really user-friendly solution if you happen to be an Arch user :)

All I'm asking is a realtively up-to-date piece on the wiki that documents steps to get it. If I understand correctly one patch landed in 4.14, so once 4.14 is out I wanted to try to get SED with sleep support.

[cristim]

I'm already using a 4.14-rc build, so I guess that patch should be already in for me.

In my case last time I tried this I struggled with getting my drive's password in the same format used by sedutil so I can pass it to the kernel as-is. I tried to capture it with gdb from a sedutil run, but I failed at this, it's been a long time since I last used gdb.

It would be nice if sedutil would be able to output the encoded password into a text file so we don't need this GDB magic anymore.

Then we just need that tool to read the password from that file and pass it to the running kernel sometime at boot.

[ScottyBauer]

I will just ad a new flag to my utility that will do the same hashing as sed-util, how about that.

[cristim]

@ScottyBauer thanks!

The tool should ideally support interactively reading the cleartext password from the console and persist its hash to a text file, then be able to consume that file and pass the hashed password directly to the kernel.

The clear password should never be persisted into a file nor passed as command line argument, which risks leaking it through the shell's history.

[badicsalex]

Hi guys, FYI I ported @kylemanna's ioctl code, and made some support-calls into sed-util (like writing the password hash to stdout). The way I use it is I read the hashed password with --printHashedPassword, and have a systemd unit that looks something like:

[Service]
Type=oneshot
ExecStart=sed-util -n -x --prepareForS3Sleep 0 92389312893ababab128912892 /dev/nvme0n1

So hardcoded password, but it's not as bad, because it's just the hash.

Right now it works great with the 4.14 kernel, so gj on that one @ScottyBauer.

[cristim]

@badicsalex it worked like a charm, huge thanks!

I just needed a small adjustment to the systemd config, to use the path where the sedutil-cli binary is deployed by make install, in my case /usr/local/sbin/sedutil-cli

[id01]

@badicsalex Awesome! :D However, now it seems like reboot doesn't work unless you power cycle the system.

[ScottyBauer]

@id01 That (the power cycle) may be due to a bug I had in the Linux kernel. It's in 4.14, sorry I missed it in the original development:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/block/sed-opal.c?h=v4.14&id=dbec491b12b52888d120e5be8f15886b3216eb19

[id01]

@ScottyBauer will there be a fix in the next version of the kernel?

[cristim]

I am running 4.14 and didn't notice any such issues at reboot, everything seems to work as expected so far

[ScottyBauer]

The fix is in 4.14, sorry I worded that sentence weird.

[id01]

@ScottyBauer ah, thanks; that must be the problem. I'm on 4.13.1 (default Arch Linux 'linux' package).

[zbraniecki]

can someone post an updated instructions on getting sleep support with 4.14 pls?

[cristim]

In a nutshell:

• install 4.14, this step depends on the distribution you are running. On Ubuntu I installed it from here
• clone, build and install the patched sedutil from @badiscalex's fork, just perform the normal sedutil build process. Once #190 is merged you can just use the mainline sedutil repo instead of the fork.
• follow the above comment by @badicsalex to create a systemd configuration that runs sedutil at boot to save the password hash to the running kernel.

We should make a script for automating all this, but I don't have the required bandwidth these days.

[davidepic91]

Hi, I'm studing some OPAL vulnerabilities from this paper paper and this video. As stated by these reaserchers, it seems that discoverd vulnerabilities are a consequence of OPAL standard itself rather than its implementation. Almost all attacks exploit the sleep mode (S3). For example the "Hot plug attack". I readed your posts, and I have some questions: 1) Is your proposed solution compliant with the OPAL standard ? If yes, I don't understand because reaserchers say that OPAL is not designed to protect data in sleep mode. 2) Until today, I thought that in Sedutil the sleep mode was disabled for security reasons and in particular to avoid those attacks. Am I wrong ? 3) Is your proposed solution strong against attacks shown by the mentioned paper ?

Thanks

[ScottyBauer]

1. Yes the solution is Opal complaint.
2. Sleep mode was never enabled in sedutil because it required Kernel support which didn't exist until kernel 4.14.
3. No.

[davidepic91]

Ok thanks. So, from answer 3, why do you enable sleep mode if it will introduce known vulnerabilities ?

[ScottyBauer]

Because some people want their laptops to turn back on after a suspend without a reboot.

[davidepic91]

Ok but there is not reason to introduce something which is knwon to be vulnerable a priori only because people want their laptops to turn back on after a suspend without a reboot. It sounds like " I want make data security easy to people but in order to do it I need to compromise security." Obvioulsy this is only my opinion ;)

[ScottyBauer]

No one is forcing you to use the feature.

[davidepic91]

Of course, I just wanted to have some other information on the topic since it is very interesting. That's all.

[zbraniecki]

I think you misunderstand the trade-off. Currently, I'm not using OPAL because I wouldn't be able to use my laptop due to lack of sleep support. Once this patch lands, I will turn on OPAL and while I still will not be secure from sleep-mode attack, I will be secure from multiple other attacks, which in total will increase my security substantially.

[davidepic91]

@zbraniecki Ok I understand your situation but from my point of view, this way of reasoning is like to put money into a safe, knowing that someone (but not everyone) knows the combination to open it. Surely it is a better solution than leaving the money on a table but I would not be evenly quiet. You're not solving the problem, but you're just changing the way someone can steal your data. I repeat, it's just my opinion.

[zbraniecki]

You're not solving the problem, but you're just changing the way someone can steal your data.

Security is not a binary game. It's a spectrum.

[davidepic91]

You are right but somethimes is like a domino structure. If a piece falls, the others may fall as well.

[badicsalex]

@davidepic91 This is not one of those times.

The security of this feature depends on your attacker model. If your presumed attacker has physical access to your computer while it's running or sleeping, or has code execution on your machine (e.g. via a malware), sure, don't use this functionality. (What will she do with that password if she already has full access though?) The attacker I'm trying to protect my laptop against is presumed to steal my powered off (not sleeping!) computer. The patch does not compromise against that.

[badicsalex]

@davidepic91 I've read the paper and watched the video. Its a non-issue. It boils down to "If an attacker has access to your running/sleping computer, she can dump all data/otherwise compromise it". It's a known thing, and they even mention some techniques, like accessing system RAM from PCIe or other DMA ports. So again, if your attacker has physical access to your running/sleeping computer, you're screwed anyway. Not OPAL, and certainly not auto-unlock-on-resume will be the weakpoint.

[davidepic91]

Ok thanks for your answer. The point I wanted to emphasize is that before the auto-unlock-on-resume patch, the sleep mode is disabled (if I'm not wrong). This means that in theory Sedutil is strong against attacks (except key capture attack) described in mentioned paper and video.

[badicsalex]

The feature is opt-in, so sedutil is as strong as it was. Also, the auto-unlock only makes the attack easier: you can put the laptop into sleep to be able to put in your SATA extender widgets. The harder option, the "hot unplug" one, i.e. the one with the special connector pins works without auto-unlock, so sedutil (or any OPAL software) was always and will always be vulnerable. TBH, you could even just attach a 5V and a 12V battery to the SSDs power pins and take it with you for later extraction.

[Venemo]

@davidepic91

1. Even if you run a kernel with the patch, you do NOT have to use this feature. If you don't tell your password to the kernel, it will not unlock your drive when your computer wakes up from sleep, thus you are protected. At the cost of the sleep feature. You decide if this is worth it.
2. If somebody steals your laptop while it is still running/sleeping and powered, they can still copy your RAM and do other nasty stuff.
3. OPAL will still protect your data if your computer is powered off when they steal it.
4. This does not need to be mentioned, but if you are a security nut, you know that the OPAL hardware implementations are not open source, therefore you cannot audit them. So if you want to be extra safe with a solution you can review and audit, use LUKS or something similar.

[davidepic91]

@Venemo Thank you, I have some comment :)

1. Ok, now this is clear.
2. I think that (as stated from reasercher in mentioned docs) the problem of sleep mode is just a "bug" of the design phase of the OPAL which could be solved by improving the specification itself (and then its implementation). Protect against RAM attacks is something that has little to do with OPAL because it is a topic which is not strictly related/due to SEDs.
3. This is clear but I'm used to reasoning by analyzing the worst case. I think that if a "stupid" employee has the possibilty to put the system in sleep, he/she will do it for sure also when a power off is more suitable. Therefore in my opinion it is better to place security before usability because you are developping a product which main scope is to provide data security.
4. Is there a document/resource explaining (at a high level) how Sedutil implements key management and encryption ? (I mean without the need to understand all the details about the code inside "Common" and "LinuxPBA").

[davidepic91]

@badicsalex "Hot unplug attack" is particular because needs the access to the drive on the "unlocked on" state (it is rurring and unlocked) for which OPAL cannot provide protection. So I think we can exclude it.

[Venemo]

@davidepic91

3, Yes, that is true. In such an environment where this is an issue, it is up to the employer to set a corporate policy for the best security.

4. sedutil does NOT implement encryption. The OPAL firmware in your drive does. As to what sedutil does and doesn't, there is a wiki area in this github repo which is well worth to read.

[davidepic91]

@Venemo ok, thank you so much.

[davidrohr]

Following up on this discussion on S3 security, @ScottyBauer wrote on Aug 8 that it would be impossible to have a prompt after S3.

In my opinion, this is basically a design flaw of OPAL. It should have been foreseen to query the password in the firmware/EFI after waking up, but then we are back to proprietary solutions like the ATA password, so anyway...

I am wondering what we could do to fix this, and what would be the technical obstacles. Clearly, there is no way to wake up userland before a password prompt, so certainly no graphical prompt. But is there some kind of EFI-framebuffer like think after waking up, that could be used to output something. I am no expert on S3, but I would assume the standard defines the GPU to be in a certain state when the resume transits from firmware to OS, e.g. to allow vendors to display vendor logos at resume. Or perhaps, it would be possible to have at least text output?

And even further, although not being ideal, for me it would even be sufficient to have no video at all: but just wait for the password from the keyboard with blank screen. Again, I assume we would need userland for USB, but is there any simple keyboard protocol present that we could use.

Btw, sorry for asking this in the blind. I am not really experience with the kernel itself and S3, but I also did not find any discussion of this anywhere yet.

[Venemo]

@davidrohr @ScottyBauer I'm not an expert in this area, but as far as I understand anything that is already in memory will stay there after suspend/resume, and only the drive is locked. So... if you can somehow take care of putting the necessary libraries and whatever in main RAM before suspend, then it could present a GUI after resume. Is this a viable option?

This would at least be consistent with the symptoms I got when not calling the new system call: after system resume everything that was already in memory would continue to work (to varying degree), everything that needed to load anything from disk would not work.

Although I can see that this presents some serious challenges, as the kernel would need to suspend every process which wants to access the disk, until the drive is unlocked. And it would have to make sure that the one process which prompts for the password is in RAM and run only that after resume.

[ScottyBauer]

An EFI Shim is probably the way to go. Theoretically you could get something to display in-os but it would require a fairly large rewrite of core mm/fault handlers/suspend code in the core kernel. This solution also would never be taken upstream, they'd never take a massive rewrite like this just to work around a broken specification.

[natterangell]

@cristim , you wrote in a comment above that in order to fix this, one needs to build sedutil with the fixes from @badicsalex on a 4.14 or newer kernel, plus put in a systemd file.

I've successfully built the sedutil-cli file with badicsalex' patches. I'm just wondering if the binary is compatible with one of the UEFI image on the Executable Distributions page, or do I need to build a new pba/image too?

I'm having problems building the pba/image. The script pulls a buildroot which includes a 4.11.8 kernel, and I get an error after compiling for a while that linux/sed-opal.h is missing.

Do I need to fix this, or can I just use one of the prebuild images?

[badicsalex]

@natterangell, my patchset's compatible with the one in the prebuilt image, I use that too :)

[cristim]

@natterangell the patched sedutil-cli created by @badicsalex is only needed in order to encode your password in a way compatible with sedutil's PBA and tell it to the running kernel after boot. Kernels as of 4.14 are able to accept and use that password to automatically unlock the drive when resuming from sleep. The PBA doesn't need to be built or reflashed.

In theory any recent kernel could also act as a PBA by itself with a very small tool that reads the password, encodes it and issues a few syscalls that unlock the drive.

[natterangell]

Awesome, it works great! Thank you so much for your efforts!