grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GRUB hardened boot framework


From: Jan Alsenz
Subject: Re: GRUB hardened boot framework
Date: Fri, 27 Feb 2009 22:56:48 +0100
User-agent: Thunderbird 2.0.0.19 (X11/20090104)

Robert Millan wrote:
> On Sun, Feb 22, 2009 at 02:27:25PM +0100, Jan Alsenz wrote:
>> If we could agree on this, then I think we could find a way to extend the 
>> GRUB
>> module system to fully allow this.
>>
>> From my point of view the minimal needed features for these systems are:
>> - easy exchange of the MBR binary to be installed
>> - easy exchange of the core.img loader binary
>> - hooks for any disk read (not sure if write is necessary)
>>
>> (I didn't check if any of these is already implemented)
>>
>> Last part to agree on would then be, that these infrastructure features 
>> should
>> be in the mainline code.
> 
> Hi,
> 
> The last stage is much simpler.  Just put /boot/ in a crypted filesystem (we
> have a patch liing around which is pending to merge).

Yes, that would also be an idea.
Then the filesystem needs the authentication.

> That only leaves MBR and core.img.  You can either check both from firmware
> (does any BIOS allow this?) or do some funny gimmicks in MBR ;-)

There might be some boot virus protections, that could be abused. Or otherwise -
coreboot.

>> That way it would be easy to develop various trusted boot solutions (and
>> probably some other systems too), but keep all the controversial code out of
>> mainline.
> 
> I appreciate your interest in avoiding controversy.  If you want that, then
> please don't refer to this as "trusted".  It is implied that all the code in
> GRUB is already trusted by its user.  The difference here is that our system
> would be hardened against physical attack, it doesn't change anything about
> who is able to "trust" your computer and who isn't.

Alright, hardened then.
Personally I would still use "trusted", but it has been a bit overly (mis)used
in the recent past, which could lead to misunderstandings.

Greets,

Jan

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]