Re: Current state of grub2 encryption support

Re: Current state of grub2 encryption support

[steve]

[-- Attachment #1: Type: text/plain, Size: 391 bytes --]

Whatever is easier for you, though a repo would be easier for me.

I have not used mailing lists before, so apologies if this message does not
appear correctly in the thread.

Thanks,
Steve
Xerces Partners


>
> I still need to get round to sorting out my copyright assignment and
> cleaning

The code up a bit. In the meantime, I can publish a patch or hg repo if
> you'd like.
>
Michael
>

[-- Attachment #2: Type: text/html, Size: 871 bytes --]

Re: Current state of grub2 encryption support

[Michael Gorven]

[-- Attachment #1: Type: text/plain, Size: 415 bytes --]

On Sunday 29 March 2009 21:54:54 steve wrote:
> Whatever is easier for you, though a repo would be easier for me.

I've published the repo at http://michael.gorven.za.net/hg/grub/luks. I merged 
with trunk this morning and fixed some compilation errors, but haven't 
actually tested it yet so it might be broken ;-)

Michael

-- 
http://michael.gorven.za.net
PGP Key ID 6612FE85
S/MIME Key ID AAF09E0E

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Current state of grub2 encryption support

[steve]

[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]

Thank you very much. The source builds and seems to function fine, I did
some experimentation loading the necessary crypto modules directly into
core.img but i believe i hit either a size limit or some other unknown
problem, so i loaded the bare necessity of minicmd, ext2, biosdisk and pc
and had it read the rest of the modules from an ext2 partition. The luks
module loads fine, finds an aes:cbc-essiv:sha256 partition and asks for the
key, seems to unlock it, and i am currently investigating why it doesn't
want to read the filesystem :) It did however produce a new device (hd2)
which i presume would be the plaintext device.

Is it going to be possible in the future to have everything needed for
crypto loaded into core.img so that an unencrypted partition is not
necessary?

Thanks,
Steve
Xerces Partners

2009/3/30 Michael Gorven <michael@gorven.za.net>

> On Sunday 29 March 2009 21:54:54 steve wrote:
> > Whatever is easier for you, though a repo would be easier for me.
>
> I've published the repo at http://michael.gorven.za.net/hg/grub/luks. I
> merged
> with trunk this morning and fixed some compilation errors, but haven't
> actually tested it yet so it might be broken ;-)
>
> Michael
>
> --
> http://michael.gorven.za.net
> PGP Key ID 6612FE85
> S/MIME Key ID AAF09E0E
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>

[-- Attachment #2: Type: text/html, Size: 2097 bytes --]

Re: Current state of grub2 encryption support

[steve]

[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]

Update, i was able to get the right modules to load into a core.img by
making the encrypted partition start at 1mb instead of 32.5kb, the modules
loaded into core.img were:

configfile sha1 fs_uuid biosdisk pc linux ext2 help minicmd crypto aes luks
sha256 devmapper

At boot, i issue the ls command which causes it to find the luks partition
and ask for the password, after that point i am able to have it read a
grub.cfg file from (lk0)/boot/grub/grub.cfg, which then loads the kernel.

So it appears to be working perfectly!

Thanks,
Steve
Xerces Partners

2009/3/30 Michael Gorven <michael@gorven.za.net>

> On Sunday 29 March 2009 21:54:54 steve wrote:
> > Whatever is easier for you, though a repo would be easier for me.
>
> I've published the repo at http://michael.gorven.za.net/hg/grub/luks. I
> merged
> with trunk this morning and fixed some compilation errors, but haven't
> actually tested it yet so it might be broken ;-)
>
> Michael
>
> --
> http://michael.gorven.za.net
> PGP Key ID 6612FE85
> S/MIME Key ID AAF09E0E
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>

[-- Attachment #2: Type: text/html, Size: 1849 bytes --]

Re: Current state of grub2 encryption support

[Michael Gorven]

[-- Attachment #1: Type: text/plain, Size: 893 bytes --]

On Tuesday 31 March 2009 04:48:02 steve wrote:
> Update, i was able to get the right modules to load into a core.img by
> making the encrypted partition start at 1mb instead of 32.5kb, the modules
> loaded into core.img were:

Nice! I briefly looked at getting everything into core.img, but it seemed 
impossible. That's a nice solution though.

> At boot, i issue the ls command which causes it to find the luks partition
> and ask for the password, after that point i am able to have it read a
> grub.cfg file from (lk0)/boot/grub/grub.cfg, which then loads the kernel.

I haven't gotten round to trying this, but ideally core.img should be 
configured to look for the config file on an encrypted partition so that it 
automatically prompts for the password and then loads the menu.

Michael

-- 
http://michael.gorven.za.net
PGP Key ID 6612FE85
S/MIME Key ID AAF09E0E

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Current state of grub2 encryption support

[phcoder]

Michael Gorven wrote:
> On Tuesday 31 March 2009 04:48:02 steve wrote:
>> Update, i was able to get the right modules to load into a core.img by
>> making the encrypted partition start at 1mb instead of 32.5kb, the modules
>> loaded into core.img were:
> 
> Nice! I briefly looked at getting everything into core.img, but it seemed 
> impossible. That's a nice solution though.

How big is the smallest core.img you could get? Have you tried applying 
my bootmove patch?

> 
>> At boot, i issue the ls command which causes it to find the luks partition
>> and ask for the password, after that point i am able to have it read a
>> grub.cfg file from (lk0)/boot/grub/grub.cfg, which then loads the kernel.
> 
> I haven't gotten round to trying this, but ideally core.img should be 
> configured to look for the config file on an encrypted partition so that it 
> automatically prompts for the password and then loads the menu.
> 
> Michael
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel


-- 

Regards
Vladimir 'phcoder' Serbinenko

Re: Current state of grub2 encryption support

[Michael Gorven]

[-- Attachment #1: Type: text/plain, Size: 729 bytes --]

On Tuesday 31 March 2009 09:50:17 phcoder wrote:
> Michael Gorven wrote:
> > On Tuesday 31 March 2009 04:48:02 steve wrote:
> >> Update, i was able to get the right modules to load into a core.img by
> >> making the encrypted partition start at 1mb instead of 32.5kb, the
> >> modules loaded into core.img were:
> >
> > Nice! I briefly looked at getting everything into core.img, but it seemed
> > impossible. That's a nice solution though.
>
> How big is the smallest core.img you could get? Have you tried applying
> my bootmove patch?

I don't know about your bootmove patch. What does it do and where can I find 
it?

Michael

-- 
http://michael.gorven.za.net
PGP Key ID 6612FE85
S/MIME Key ID AAF09E0E

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Current state of grub2 encryption support

[phcoder]

Michael Gorven wrote:
> On Tuesday 31 March 2009 09:50:17 phcoder wrote:
>> Michael Gorven wrote:
>>> On Tuesday 31 March 2009 04:48:02 steve wrote:
>>>> Update, i was able to get the right modules to load into a core.img by
>>>> making the encrypted partition start at 1mb instead of 32.5kb, the
>>>> modules loaded into core.img were:
>>> Nice! I briefly looked at getting everything into core.img, but it seemed
>>> impossible. That's a nice solution though.
>> How big is the smallest core.img you could get? Have you tried applying
>> my bootmove patch?
> 
> I don't know about your bootmove patch. What does it do and where can I find 
> it?
> 
It moves loader.c out of the kernel and boot command out of minicmd into 
separate module named boot.mod. It's on this list
"Move loader.c out of the kernel" 03/22/2009 01:48 PM
How big is your core.img?
> Michael
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel


-- 

Regards
Vladimir 'phcoder' Serbinenko

Re: Current state of grub2 encryption support

[Michael Gorven]

[-- Attachment #1: Type: text/plain, Size: 279 bytes --]

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

-- 
http://michael.gorven.za.net
PGP Key ID 6612FE85
S/MIME Key ID AAF09E0E

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Current state of grub2 encryption support

[phcoder]

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

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

[phcoder]

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