All of lore.kernel.org
 help / color / mirror / Atom feed
* Design: first sector of core.img
@ 2009-02-20 22:12 phcoder
  2009-02-21 14:09 ` Robert Millan
  0 siblings, 1 reply; 2+ messages in thread
From: phcoder @ 2009-02-20 22:12 UTC (permalink / raw)
  To: The development of GRUB 2

Hello. For SHA-1 verified boot first sector needs to check the rest of 
core.img. It will need heavy modifications. On the same time I would 
like to avoid changes to current boot process so that both alternatives 
are available (SHA-1 and plain boot). In the same time even in current 
design the first sector plays a special role. So I propose first sector 
to be moved to a separate file and then at install time grub-mkimage or 
grub-setup can take care of choosing right one depending on options 
supplied by user (plain or SHA-1 boot)
Regards
Vladimir 'phcoder' Serbinenko



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Design: first sector of core.img
  2009-02-20 22:12 Design: first sector of core.img phcoder
@ 2009-02-21 14:09 ` Robert Millan
  0 siblings, 0 replies; 2+ messages in thread
From: Robert Millan @ 2009-02-21 14:09 UTC (permalink / raw)
  To: The development of GRUB 2

On Fri, Feb 20, 2009 at 11:12:25PM +0100, phcoder wrote:
> Hello. For SHA-1 verified boot first sector needs to check the rest of  
> core.img. It will need heavy modifications. On the same time I would  
> like to avoid changes to current boot process so that both alternatives  
> are available (SHA-1 and plain boot). In the same time even in current  
> design the first sector plays a special role. So I propose first sector  
> to be moved to a separate file and then at install time grub-mkimage or  
> grub-setup can take care of choosing right one depending on options  
> supplied by user (plain or SHA-1 boot)

Have you looked at how the boot process works when using coreboot/GRUB ?
By getting rid of the legacy stuff, things get much more flexible.

Check the grub.cfg example in:

  http://grub.enbug.org/CoreBoot

to see what I mean.  Most pieces are there already.  When we merge crypto
support, it'll be possible for GRUB-in-chip to verify GRUB-in-disk.

Then the chip becomes your root of trust, which is what you're pursuing, if I
understood correctly.  But if I was serious about security, I wouldn't make
a BIOS blob my root of trust, GRUB is a much better option ;-)

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2009-02-21 14:10 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-02-20 22:12 Design: first sector of core.img phcoder
2009-02-21 14:09 ` Robert Millan

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.