Message-ID: <alpine.LRH.2.21.1905132354150.6401@linux.fjfi.cvut.cz>
Date:   Tue, 14 May 2019 00:12:33 +0200 (CEST)
From:   David Kozub <zub@...ux.fjfi.cvut.cz>
To:     Scott Bauer <sbauer@...donthack.me>
cc:     Christoph Hellwig <hch@...radead.org>,
        Jens Axboe <axboe@...nel.dk>,
        Jonathan Derrick <jonathan.derrick@...el.com>,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        Jonas Rabenstein <jonas.rabenstein@...dium.uni-erlangen.de>
Subject: Re: [PATCH 0/3] block: sed-opal: add support for shadow MBR done
 flag and write

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

Powered by blists - more mailing lists