crypto space considerations (Re: Current state of grub2 encryption support)

[phcoder <phcoder@gmail.com>]

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