From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LqZKA-0004J2-CE for mharc-grub-devel@gnu.org; Sun, 05 Apr 2009 16:52:14 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LqZK8-0004I0-AU for grub-devel@gnu.org; Sun, 05 Apr 2009 16:52:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LqZK7-0004Hc-7t for grub-devel@gnu.org; Sun, 05 Apr 2009 16:52:11 -0400 Received: from [199.232.76.173] (port=49151 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LqZK7-0004HZ-5V for grub-devel@gnu.org; Sun, 05 Apr 2009 16:52:11 -0400 Received: from fg-out-1718.google.com ([72.14.220.157]:57109) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LqZK6-0004h5-5R for grub-devel@gnu.org; Sun, 05 Apr 2009 16:52:10 -0400 Received: by fg-out-1718.google.com with SMTP id l27so151783fgb.7 for ; Sun, 05 Apr 2009 13:52:09 -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=JzazFpH84TFYc8rvkW1kcqMT/Y7WqLmjSssTRYlwst8=; b=OjOMy27zr1XDf70FxjhRiFsDlRqBMBXO/8aHb32dCvIP8dqmtefnrAstkehCNrucHt SLZsQ2R1lfE2XXIPLHGRkEcWsVXf9OeomFqvmphK5j8cuMM8vAUq10Szpxmmg4C0q8ZU SJ7l/MNYHNTVAN880LlnQhtTizKnSd9kg67rI= 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=apR3BXklj5FuNZn2bx5GnSzg13ryeltADfuRf5kd/f95VaMwsPDmrWHQoOFZI90z0d Da8I+ie978nQcoB1rL4w+/4Hff+ZoKJ7idswdf4Y2L1gjs051K1mTLCA/ynWJT1kd//d +rV33F9lnQ0iWX49ogeXVzx83NEEBTnNqUDMo= Received: by 10.86.90.2 with SMTP id n2mr2073652fgb.79.1238964728781; Sun, 05 Apr 2009 13:52:08 -0700 (PDT) Received: from ?192.168.1.2? (52-101.3-85.cust.bluewin.ch [85.3.101.52]) by mx.google.com with ESMTPS id d6sm6243902fga.2.2009.04.05.13.52.08 (version=SSLv3 cipher=RC4-MD5); Sun, 05 Apr 2009 13:52:08 -0700 (PDT) Message-ID: <49D919FA.1070203@gmail.com> Date: Sun, 05 Apr 2009 22:52:10 +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> <49D21028.6020706@gmail.com> In-Reply-To: <49D21028.6020706@gmail.com> 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: crypto space considerations (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: Sun, 05 Apr 2009 20:52:12 -0000 As I already stated on the IRC libgcrypt modules are optimized for speed and not the performance (e.g. main loop of sha1 is repeated multiple times with minor modifications to avoid if's). Generally it's ok to optimize for speed but in context of embedding size is more important. On the other hand some OSes require grub to load big files (e.g. solaris requires 70 MB). On powerful CPUs speed optimization doesn't play any role since bottleneck is the I/O. However in the case of low-powered CPUs it may make a difference. One possibility is to have 2 modules: one size and one speed optimized and to dynamically switch between them. In this case size-optimized versions can be even written in asm since space isn't an issue on supported non-i386 platforms (but it may change in the future). In any case I think we should keep speed-optimized versions of ciphers for which we have no size-optimized variant phcoder wrote: > 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