All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Alsenz <janalsenz@student.ethz.ch>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: GRUB hardened boot framework
Date: Fri, 27 Feb 2009 22:56:48 +0100	[thread overview]
Message-ID: <49A861A0.2000601@student.ethz.ch> (raw)
In-Reply-To: <20090227204226.GI31629@thorin>

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

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

  reply	other threads:[~2009-02-27 21:59 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-22 13:27 GRUB trusted boot framework Jan Alsenz
2009-02-22 13:56 ` phcoder
2009-02-22 15:12   ` Jan Alsenz
2009-02-22 15:42     ` phcoder
2009-02-22 16:48       ` Jan Alsenz
2009-02-22 17:15         ` phcoder
2009-02-22 16:07 ` Vesa Jääskeläinen
2009-02-22 18:31   ` Jan Alsenz
2009-02-22 18:45     ` Vesa Jääskeläinen
2009-02-22 19:16       ` Jan Alsenz
2009-02-22 21:16         ` phcoder
2009-02-22 23:04           ` Jan Alsenz
2009-02-22 23:55             ` phcoder
2009-02-23  7:51               ` Jan Alsenz
2009-02-27 20:42 ` Robert Millan
2009-02-27 21:56   ` Jan Alsenz [this message]
2009-02-27 22:15     ` GRUB hardened " phcoder
2009-02-27 22:22     ` Robert Millan
2009-02-27 22:55       ` phcoder
2009-02-27 23:08         ` Robert Millan
2009-02-27 23:16           ` phcoder
2009-02-27 23:10         ` Jan Alsenz
2009-02-27 23:18           ` phcoder
2009-02-27 23:26             ` Robert Millan
2009-02-28  0:07               ` Jan Alsenz

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=49A861A0.2000601@student.ethz.ch \
    --to=janalsenz@student.ethz.ch \
    --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.