Re: [PATCH 0/3] block: sed-opal: add support for shadow MBR done flag and write

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 5 May 2019, Scott Bauer wrote:

On Fri, May 03, 2019 at 10:32:19PM +0200, David Kozub wrote:
On Wed, 1 May 2019, Christoph Hellwig wrote:

I successfully tested toggling the MBR done flag and writing the shadow MBR
using some tools I hacked together[4] with a Samsung SSD 850 EVO drive.

Can you submit the tool to util-linux so that we get it into distros?

There is already Scott's sed-opal-temp[1] and a fork by Jonas that adds
support for older version of these new IOCTLs[2]. There was already some
discussion of getting that to util-linux.[3]

While I like my hack, sed-opal-temp can do much more (my tool supports just
the few things I actually use). But there are two things which sed-opal-temp
currently lacks which my hack has:

* It can use a PBKDF2 hash (salted by disk serial number) of the password
  rather than the password directly. This makes it compatible with sedutil
  and I think it's also better practice (as firmware can contain many
  surprises).

* It contains a 'PBA' (pre-boot authorization) tool. A tool intended to be
  run from shadow mbr that asks for a password and uses it to unlock all
  disks and set shadow mbr done flag, so after restart the computer boots
  into the real OS.

@Scott: What are your plans with sed-opal-temp? If you want I can update
Jonas' patches to the adapted IOCTLs. What are your thoughts on PW hashing
and a PBA tool?

I will accept any and all patches to sed opal tooling, I am not picky. I will
also give up maintainership of it is someone else feels they can (rightfully
so) do a better job.

Jon sent me a patch for the tool that will deal with writing to the shadow MBR,
so once we know these patches are going in i'll pull that patch into the tool.

Then I guess that leaves PBKDF2 which I don't think will be too hard to pull in.

After (if) these patches are accepted, I can create a patch that adds it to sed-opal-temp.

With regard to your PBA tool, is that actually being run post-uefi/pre-linux?
IE are we writing your tool into the SMBR and that's what is being run on bootup?

It's actually nothing fancy: It's just a linux program that asks for a password and then uses it to unlock all block devices. It's intended to be run from an initramfs. So the idea is you build a kernel + initramfs with the tool so that the tool it started and after the tool returns, initramfs does a reboot. This could be replaced just by a shell script, though then you'd have to pass the password from the shell script to e.g. sed-opal-temp.

But I think it covers the simple scenario: booting from a locked drive with just one locking range. Possibly with other locked drives connected that also have one locking range and use the same password (when using pwd hash at least the Opal key is not the same).

Jon, if you think it's a good idea can you ask David if Revanth or you wants
to take over the tooling? Or if anyone else here wants to own it then let me know.

I got invoved in this just to scratch an itch so I would not be a good candidate.

Best regards,
David



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux