All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Protection of boot sector and embedded area
Date: Sun, 27 Sep 2009 14:41:33 +0200	[thread overview]
Message-ID: <4ABF5D7D.8060404@gmail.com> (raw)
In-Reply-To: <ad2655cb0909270521n683a772frfd3cc4b30224a0a7@mail.gmail.com>

James Courtier-Dutton wrote:
> 2009/9/27 Michal Suchanek <hramrach@centrum.cz>:
>   
>> Obviously your encryption solution does not encrypt the linux volume
>> which you boot using the USB stick so it has no reason to be loaded
>> when loading Linux, it can only cause harm by trying to decrypt what
>> is not encrypted.
>>     
> You make a assumption that the encryption program would cause harm. It does not.
> One specifies which partitions to encrypt/decrypt and it leaves the rest alone.
>
>   
It's loaded uselessly. Actually normally there is no reason to encrypt
any of the files grub accesses. But authenticating files is needed.
(encryption doesn't prevent attacker from modifying files)
Encrypting is to keep secret
MAC or signatures is to keep unmodified.
GRUB and most OSes we support are free software so there is no reason to
keep them secret. Even proprietary for kernels you have, the binaries
aren't secret.
There are two reason full disk encryption exists:
1) "I have everything encrypted" is a good confidence-giving sentence
and good for marketing
2) If you encrypt everything you have no risk of forgetting encrypting
something (typical examples: swap, /tmp, /var/tmp). This renders the
approach fool-proof and easy to configure
>> Also as Grub can access the disk drives by various means (BIOS, PCI
>> device driver, ...) the encryption software would have to hijack all
>> these access paths transparently which I can't imagine happening.
>>
>>     
> One would obviously need grub to only use BIOS calls and no direct PCI
> device access for it to work together with the whole disc encryption
> program in pre-boot stages. 
The only reason we keep BIOS calls by default is that our own drivers
don't work in all configurations.
> Alternatively, one would have to add
> encryption support into grub itself that is not a good idea.
>   
We have patches to do so. While encrypting a part of bootloader and a
kernel isn't security-improving, it renders encrypted configuration
easier (no need for separate /boot). So I'm favorable to it. Why do you
say it's a bad idea?
Signatures in grub are on todo list.
> I think that maybe being able to install grub into it's own small
> partition instead of the embedded area would be all I would need.
>   
I explained why this "all I need" is problematic
> Kind Regards
>
> James
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   




  reply	other threads:[~2009-09-27 12:41 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-26  8:28 Protection of boot sector and embedded area James Courtier-Dutton
2009-09-26  8:57 ` Colin Watson
2009-09-26  9:07   ` James Courtier-Dutton
2009-09-26  9:13     ` Colin Watson
2009-09-26 10:40       ` James Courtier-Dutton
2009-09-26 10:47         ` Felix Zielcke
2009-09-26 14:49     ` Vladimir 'phcoder' Serbinenko
2009-09-26 21:57       ` James Courtier-Dutton
2009-09-26 22:07         ` Vladimir 'phcoder' Serbinenko
2009-09-26 22:47           ` James Courtier-Dutton
2009-09-26 23:01             ` Vladimir 'phcoder' Serbinenko
2009-09-27 11:37             ` Michal Suchanek
2009-09-27 12:21               ` James Courtier-Dutton
2009-09-27 12:41                 ` Vladimir 'phcoder' Serbinenko [this message]
2009-09-26 22:12         ` Vladimir 'phcoder' Serbinenko

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=4ABF5D7D.8060404@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.