All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vesa Jääskeläinen" <chaac@nic.fi>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: GRUB trusted boot framework
Date: Sun, 22 Feb 2009 20:45:59 +0200	[thread overview]
Message-ID: <49A19D67.2060003@nic.fi> (raw)
In-Reply-To: <49A19A05.6030606@student.ethz.ch>

Jan Alsenz wrote:
> Vesa Jääskeläinen write:
>> I do like the idea what some protected systems use, they sign the binary
>> (in our case .mod file and kernels of loaded OSes). Now in that scenario
>> it is responsibility of the kernel module loader to first verify the
>> signature for correctness. This way the signature checking would be
>> somewhat transparent to the rest of the system.
>>
>> I do not see a need to add any hooks to disk read. It should be
>> responsibility of the code needing signature checking to handle that.
> 
> Well, since to trusted operation should be transparent (and in my opinion should
> not need code changes in something like the loaders - so if someone writes a new
> loader, it should work by default), that's where the hooks come in.
> Maybe the "disk read" was misleading, what I meant where "file reads".

Hi,

Well.. you probably don't want to verify authenticity of the fonts or
bitmaps in graphical menu?

Anyway. I think the right place for verification hook in this case is
the module or OS kernel loader.

If you think otherwise. Then you have to provide a complete technical
design how it should work as I see no other good choice for it.

(actually there is one other place that could be used, but I let you
come up with the idea after you have given a bit more though on the
implementation side :))

Thanks,
Vesa Jääskeläinen



  reply	other threads:[~2009-02-22 18:46 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 [this message]
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   ` GRUB hardened " Jan Alsenz
2009-02-27 22:15     ` 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=49A19D67.2060003@nic.fi \
    --to=chaac@nic.fi \
    --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.