From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hpYXMisR9sR for ; Sat, 30 Nov 2013 18:33:06 +0100 (CET) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Sat, 30 Nov 2013 18:33:06 +0100 (CET) Received: by mail-ea0-f176.google.com with SMTP id h14so7497090eaj.7 for ; Sat, 30 Nov 2013 09:33:05 -0800 (PST) Message-ID: <529A214E.1060305@gmail.com> Date: Sat, 30 Nov 2013 18:33:02 +0100 From: Milan Broz MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] GEOM_ELI support in dm-crypt/cryptsetup List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: f000m@z1p.biz Cc: dm-crypt@saout.de Hi, On 11/30/2013 04:25 PM, f000m@z1p.biz wrote: > I am planing to make dm-crypt and cryptsetup able to > handle FreeBSD's GEOM_ELI crypted devices (without its > integrity stuff). I think that even integrity stuff would be interesting but that's a lot of kernel work. (But I am quite interested how FreeBSD approach looks like anyway.) > In the kernel modul there would be minor changes > concerning two more IV generators needed to add: > First, because of a slightly different handling of plain type > (it uses offsets instead of sectors). > Second, GEOM_ELI uses CBC with unpredictable IV instead of > ESSIV Mode. Not sure I understand offset/sectors problem. Can you elaborate more here? Is it just multiplication of sector number by sector size or something else? (Or just point me to the docs :) Anyway, adding new IV generators to dmcrypt should not be big problem (in principle). > Additionally cryptsetup must be patched to be able > to deal with the metadata structure of GEOM_ELI devices. > > Would there be any interests in committing me this code > to the upstream? Well, I am not sure how broadly this format is used and if there are potential users in Linux world, so if you can post more description here it would be nice. (And if anyone on list is interested, plesase say so... now :) But in general, yes, I think it is good idea. I would suggest you to do these steps: 1) provide links to documentation of format, limitation of your approach etc (also should be included in patch later) 2) first, implement needed changes in Linux kernel (dmcrypt IVs) (if it is only new IV, it should be straightforward) Please post patches to DM devel list (dm-devel@redhat.com) This should be done in advance - for testing, you can use dmsetup to configure dmcrypt device and test it works for your images. Cryptsetup support can come later (we need patch in stable kernel first to release build supporting it). 3) second, post patches for cryptsetup to this list. Please keep format specific code in separate directory, lib/geli/* or so. (I am planning some unified interface for formats in future (1.7), so see how is e.g. TCRYPT done - it should be very similar). Please post at least simple regression tests together with patches (see tests/ dir). License of new code must be compatible with released code, basically GPL2+/LGPL2.1+ for cryptsetup. (And be prepared it will take some time and perhaps reiterated patch posts - mainly for kernel part :) Thanks, Milan