All of lore.kernel.org
 help / color / mirror / Atom feed
From: Darren J Moffat <Darren.Moffat@Oracle.COM>
To: The development of GNU GRUB <grub-devel@gnu.org>
Cc: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
Subject: Re: ZFS Crypto key hand off to kernel
Date: Fri, 13 Jan 2012 14:27:09 +0000	[thread overview]
Message-ID: <4F103F3D.3090103@Oracle.COM> (raw)
In-Reply-To: <4F103D17.4020903@gmail.com>

On 01/13/12 14:17, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> Is this something that would be of interest for GRUB2 ? If so I'll
>> look at developing the spec update and a patch for GRUB2 to support it
>> for the zfs crypto support.
>>
> That would be most welcome. The main issues are:
> 1) What to consider a key? IMHO it should be the master key, and not
> password or session key.

Agreed, it is really helpful that GRUB2 has already done the PKCS#5 PBE 
transform in the case of a ZFS encrypted dataset. So there is no need to 
give the passphrase to the kernel when you can give the real key.

Also it wouldn't actually be useful in the case of ZFS encryption for 
GRUB2 to hand off the list of actual data encryption keys all we need is 
the key encryption key (aka master key, aka wrapping key).

> 2) How to match keys to actual devices? I think it should be UUID for
> LUKS and POOLUUID+FSNAME for ZFS, or perhaps just POOLUUD.

I need to brush up on LUKS it has been a while since I looked at it but 
that sounds correct to me.

For ZFS I think it might be enough to give the dataset name but I like 
the idea of passing the POOL GUID as well. If I had both I would 
certainly use them.

> 3) GRUB may have some keys without knowing which pool/fs it's used for.
> They should be marked as such.

I must be missing something here, how could that happen in the ZFS case? 
Or do you mean in general ?

-- 
Darren J Moffat


  reply	other threads:[~2012-01-13 14:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-10 12:23 ZFS Crypto key hand off to kernel Darren J Moffat
2012-01-13 14:17 ` Vladimir 'φ-coder/phcoder' Serbinenko
2012-01-13 14:27   ` Darren J Moffat [this message]
2012-01-13 16:10     ` Vladimir 'φ-coder/phcoder' Serbinenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F103F3D.3090103@Oracle.COM \
    --to=darren.moffat@oracle.com \
    --cc=grub-devel@gnu.org \
    --cc=phcoder@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.