All of lore.kernel.org
 help / color / mirror / Atom feed
From: phcoder <phcoder@gmail.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Current state of grub2 encryption support
Date: Tue, 31 Mar 2009 14:44:24 +0200	[thread overview]
Message-ID: <49D21028.6020706@gmail.com> (raw)
In-Reply-To: <200903311252.45612.michael@gorven.za.net>

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



  reply	other threads:[~2009-03-31 12:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-29 19:54 Current state of grub2 encryption support steve
2009-03-30 11:06 ` Michael Gorven
2009-03-31  1:56   ` steve
2009-03-31  2:48   ` steve
2009-03-31  7:45     ` Michael Gorven
2009-03-31  7:50       ` phcoder
2009-03-31  8:15         ` Michael Gorven
2009-03-31  8:50           ` phcoder
2009-03-31 10:52             ` Michael Gorven
2009-03-31 12:44               ` phcoder [this message]
2009-04-05 20:52                 ` crypto space considerations (Re: Current state of grub2 encryption support) phcoder
  -- strict thread matches above, loose matches on Subject: below --
2009-03-28 22:52 Current state of grub2 encryption support steve
2009-03-29  7:17 ` Michael Gorven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49D21028.6020706@gmail.com \
    --to=phcoder@gmail.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.