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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
