From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1RljiJ-0004Qk-09 for mharc-grub-devel@gnu.org; Fri, 13 Jan 2012 11:10:47 -0500 Received: from eggs.gnu.org ([140.186.70.92]:58385) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RljiG-0004PZ-9I for grub-devel@gnu.org; Fri, 13 Jan 2012 11:10:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RljiF-00049a-AL for grub-devel@gnu.org; Fri, 13 Jan 2012 11:10:44 -0500 Received: from mail-ww0-f49.google.com ([74.125.82.49]:51346) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RljiF-00049W-4M for grub-devel@gnu.org; Fri, 13 Jan 2012 11:10:43 -0500 Received: by wgbdt13 with SMTP id dt13so2918696wgb.30 for ; Fri, 13 Jan 2012 08:10:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hVzU01yr0ZD7ONbotWT1o2axDOFErhMjc8ppifcGYAI=; b=snllWR/9SWptm07DVp1aPkuOrE834CP2xPcBqVjzepE5W1YxMqetoLdHPtfGnexVER H9VU6yrySqRqrKpVeSQH3ruyeztrgKGZ7ombLj0MyV2yEFOZEyXB2ScpsCa4oNXsgRKK B8CQV5DJWTb2Dty96Lw4EkfmWXkIOifjRJrjg= Received: by 10.180.104.5 with SMTP id ga5mr940548wib.21.1326471042242; Fri, 13 Jan 2012 08:10:42 -0800 (PST) Received: from debian.x201.phnet (49-234.197-178.cust.bluewin.ch. [178.197.234.49]) by mx.google.com with ESMTPS id l2sm4163623wie.11.2012.01.13.08.10.39 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Jan 2012 08:10:40 -0800 (PST) Message-ID: <4F10577C.7020001@gmail.com> Date: Fri, 13 Jan 2012 17:10:36 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: Darren J Moffat Subject: Re: ZFS Crypto key hand off to kernel References: <4F0C2DDE.7070703@Oracle.COM> <4F103D17.4020903@gmail.com> <4F103F3D.3090103@Oracle.COM> In-Reply-To: <4F103F3D.3090103@Oracle.COM> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 74.125.82.49 Cc: The development of GNU GRUB X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 16:10:45 -0000 On 13.01.2012 15:27, Darren J Moffat wrote: > 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 ? > I mean exactly the ZFS case. zfskey only stores the password and files in a special place and on an attempt to read encrypted data, the real key is decoded. IF no such attempt has been made, they key won't be decoded and GRUB won't know what it's for. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko