From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LodKb-0007dc-Ou for mharc-grub-devel@gnu.org; Tue, 31 Mar 2009 08:44:42 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LodKU-0007bb-AB for grub-devel@gnu.org; Tue, 31 Mar 2009 08:44:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LodKP-0007aQ-0O for grub-devel@gnu.org; Tue, 31 Mar 2009 08:44:32 -0400 Received: from [199.232.76.173] (port=53678 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LodKO-0007Zx-BO for grub-devel@gnu.org; Tue, 31 Mar 2009 08:44:28 -0400 Received: from mail-bw0-f167.google.com ([209.85.218.167]:50977) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LodKN-0005dY-IB for grub-devel@gnu.org; Tue, 31 Mar 2009 08:44:27 -0400 Received: by bwz11 with SMTP id 11so2250776bwz.42 for ; Tue, 31 Mar 2009 05:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=QhPGG3h19nyOeWtOWmlbrR2lgQV5SmTWsXmvb3h89fU=; b=HJ0zDMxWHt4Q729msJLml56/KaXeQucnoHUWjJfsjKqV8QjZNwiFOjjzcGrFBgk9Vj 8rw9lqqhWT9MkoPpuwQSzGcQTFMoNbTOsvE/JTGPGRe79vA+EoiksPfWe8QZ8O9pwPEO ptsLYi7uYQt4+yaWR4uZ7mpeVGLDzZwQk2sT8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Os9Rx/j3RdQ2tGc3b0xulFtaodjdH1mZ778F9okyFuIMUJR+FBBTTBIG8fLiV8Prdx GIRhnohC/qVknc1HYWrhrsTP5ixI1JRcvdVmAIc3Mk0DfBpP5yj2LbR+b1TBsH43QfAK vdTonNIlq/b+1NeAF+86lgOuN9pj7TOFSjnIk= Received: by 10.223.124.17 with SMTP id s17mr3701592far.79.1238503465585; Tue, 31 Mar 2009 05:44:25 -0700 (PDT) Received: from ?129.132.210.95? (vpn-global-dhcp3-095.ethz.ch [129.132.210.95]) by mx.google.com with ESMTPS id c28sm2846438fka.6.2009.03.31.05.44.24 (version=SSLv3 cipher=RC4-MD5); Tue, 31 Mar 2009 05:44:24 -0700 (PDT) Message-ID: <49D21028.6020706@gmail.com> Date: Tue, 31 Mar 2009 14:44:24 +0200 From: phcoder User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: The development of GRUB 2 References: <4b0e68160903291254u26b4dd18g4f974116e97b70c7@mail.gmail.com> <200903311015.52766.michael@gorven.za.net> <49D1D971.6020706@gmail.com> <200903311252.45612.michael@gorven.za.net> In-Reply-To: <200903311252.45612.michael@gorven.za.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: Current state of grub2 encryption support X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 12:44:35 -0000 Michael Gorven wrote: > On Tuesday 31 March 2009 10:50:57 phcoder wrote: >> How big is your core.img? > > With the following modules (untested), 61K. > configfile sha1 biosdisk pc linux ext2 minicmd crypto aes luks sha256 You don't need to embed linux.mod to the kernel, it can very weel be loaded from encrypted partition. configfile and luks depend on normal.mod. It shouldn't be the case. configfile shouldn't be needed in this context at all. minicmd isn't needed either luks should be able to retrieve the password without using normal mode. Using grub_cmdline_get for retrieving password is IMO wrong. It has features like kill and yank which nobody needs when entering password. Also it adds the password to the history When I commented out the line in luks.c to retrieve the password (to remove normal.mod dependency), apply my bootmove patch with following modules: biosdisk pc ext2 crypto aes sha256 luks sha1 I get a core.img of the size 40992 bytes. While still 9248 bytes bigger then the mbr gap (31744) it's already nearer to the goal Alternatively it's possible to embed grub in the space reserved for future AF stripes of unused key slot. The disadvantage is the need to reinstall after key change. IMO this way shouldn't be taken. But we can contact LUKS people and ask them to add embeding space for grub2. It's enough to just shift everything by 1 MiB on devices bgger then 256 MiB, and by 256 Kib on devices bigger then 64 MiB (can be overriden at format time), then make luks code look for the header at 0, 256KiB and 1 MiB > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'phcoder' Serbinenko