From: phcoder <phcoder@gmail.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: SHA-1 MBR
Date: Sat, 21 Feb 2009 14:27:42 +0100 [thread overview]
Message-ID: <49A0014E.6070002@gmail.com> (raw)
In-Reply-To: <499FC1BC.1050007@student.ethz.ch>
I consider the way how memory is protected or how integrity of mbr is
ensured out of scope of grub2. It simply can do nothing against it. So
my goals is just making verfication chain secure. Then I hope that
someone more knowledge in chipsets will find a way to build a secure
system on the top of it. I do only as much as I can and never claim to
achieve something which is theoretically impossible
Regards
Vladimir 'phcoder' Serbinenko
Jan Alsenz wrote:
>>>> If not, who checks the MBR?
>>> This can't be done by grub because it happens before any part of grub is
>>> loaded. to verify grub you need to rely on vendor/platform-specific
>>> mechanisms.
>>> I personally find "tpm without tpm" more attractive because it can be
>>> easily reused on another platform or any alternative to tpm (perhaps
>>> anybody here or coreboot folks will come up with something).
>>> Additionally it workarounds many bios and tpm bugs.
>>> I will continue working on sha-1 boot. My goal is to load core.img
>>> checked. After that point there is much more space and any signature
>>> based solution can be used.
>> Yes, that was my point. You need a trusted first step.
>> But the only thing besides a TPM, that can be used for this is the BIOS, which
>> can be flashed.
>> And even, if we assume, that we can construct a BIOS that only boots if the MBR
>> hash matches and can not be flashed prior to this point, there are still two
>> points missing:
>> - After the system has started, the BIOS could be flashed. This is a very
>> possible scenario in a multi user environment.
> Ok, I revoke that statement!
>
> This is most likely equivalent to being able to just read out the disk
> encryption keys from memory, which we considered out of scope.
>
> So if you can get the BIOS right, this might actually work for our scenario!
>
> Greets,
>
> Jan
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
next prev parent reply other threads:[~2009-02-21 13:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-20 21:50 SHA-1 MBR phcoder
2009-02-20 23:06 ` Jan Alsenz
2009-02-20 23:41 ` phcoder
2009-02-21 0:32 ` Jan Alsenz
2009-02-21 1:02 ` Isaac Dupree
2009-02-21 1:21 ` Javier Martín
2009-02-21 9:43 ` phcoder
2009-02-21 8:56 ` Jan Alsenz
2009-02-21 13:27 ` phcoder [this message]
2009-02-21 14:12 ` phcoder
-- strict thread matches above, loose matches on Subject: below --
2009-02-21 2:21 Alex Besogonov
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=49A0014E.6070002@gmail.com \
--to=phcoder@gmail.com \
--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.