All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. Tilmann Bubeck" <t.bubeck@reinform.de>
To: grub-devel@gnu.org
Subject: Re: GRUB and the risk of block list corruption in extX
Date: Fri, 03 May 2013 21:21:47 +0200	[thread overview]
Message-ID: <51840E4B.1010807@reinform.de> (raw)
In-Reply-To: <518373A2.1030300@ts.fujitsu.com>

There is a solution under way. Linux 3.10 will include code written by 
me to secure core.img of grub when running from ext4. This means, that 
ext4 will be as safe to use for grub chainloading as btrfs or any other 
filesystem offering "embedding".

I am currently extending grub-setup.c to use this new functionality. I 
will send a patch to this list in a few days. Hopefully you can apply 
this patch, so that this issue will be fixed.

Kind regards,
  Till


Am 03.05.2013 10:21, schrieb Martin Wilck:
> Andrey,
>
>> Here is example how using filesystem blocklists may lead to unbootable
>> system without any extX corruption involved.
>>
>> - user sets up multiboot system with Windows as primary bootloader
>> - standard technique to add Linux loaders has always been - copy
>>    partition boot sector and "launch" it from Windows loader
>> - user copies Linux partition boot sector which points to core.imng
>>    absolute disk position
>> - user updates grub in Linux. core.img is rewritten and its position
>>    changes
>> - next time user tries to boot Linux (s)he gets blinking cursor
>>
>> So *any* third party bootloader that relies on being able to
>> "chainload" *copy* of boot sector will give you the same issue.
>
> I understand. It's generally understood that updating core.img without
> updating the boot sector is a bad idea. In this particular case updating
> the boot sector is not enough because the copy needs to be updated, too.
>
> The background for my question was a different scenario, with a
> chainload-capable boot loader in the MBR and secondary boot loaders in
> partition boot sectors. It is that scenario that the new anaconda
> installer doesn't support any more, and the major argument from the
> Fedora devs for this (apart from sparing dev and QA resources) was the
> warning emitted by GRUB when users try to install using block lists.
>
> I am still convinced that the risk of boot loader corruption in that
> scenario is extremely low.
>
> Martin
>


-- 
+-------+-------------------------------------------------------------+
|       | dr. tilmann bubeck               reinform medien- und       |
|       |                                  informationstechnologie AG |
| rein  | fon  : +49 (711) 7 82 76-52      loeffelstr. 40             |
| form  | fax  : +49 (711) 7 82 76-46      70597 stuttgart / germany  |
|    AG | cell.: +49 (172) 8 84 29 72      fon: +49 (711) 75 86 56-10 |
|       | email: t.bubeck@reinform.de      http://www.reinform.de     |
|       +-------------------------------------------------------------+
|       | pflichtangaben nach paragraph 80, AktG:                     |
|       | reinform medien- und informationstechnologie AG, stuttgart  |
|       | handelsregister stuttgart, HRB 23001                        |
|       | vorstand:     dr. tilmann bubeck (vorsitz)                  |
|       | aufsichtsrat: frank stege (vorsitz)                         |
+-------+-------------------------------------------------------------+


  reply	other threads:[~2013-05-03 19:21 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-07 10:47 GRUB and the risk of block list corruption in extX Martin Wilck
2013-02-08 11:44 ` Martin Wilck
2013-02-08 16:57 ` Vladimir 'phcoder' Serbinenko
2013-02-08 17:17   ` Vladimir 'phcoder' Serbinenko
2013-02-08 17:17   ` Martin Wilck
2013-02-08 18:42     ` Lennart Sorensen
2013-02-08 18:56       ` Bruce Dubbs
2013-02-08 18:58         ` Lennart Sorensen
2013-02-08 19:11           ` Andrey Borzenkov
2013-02-18 15:42       ` Martin Wilck
2013-02-09  6:22     ` Chris Murphy
2013-02-18 17:16       ` Martin Wilck
2013-02-18 21:07         ` Chris Murphy
2013-02-19  5:02           ` Andrey Borzenkov
2013-02-19  6:24             ` Chris Murphy
2013-02-19  8:43               ` Michael Chang
2013-02-19  9:06                 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-02-19 18:54                 ` Chris Murphy
2013-02-19  8:47           ` Martin Wilck
2013-02-19 18:56             ` Chris Murphy
2013-02-19 19:46               ` Martin Wilck
2013-02-19  9:37           ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-02-19 12:58             ` Martin Wilck
2013-02-19 15:48               ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-02-19 17:17                 ` Martin Wilck
2013-02-19  5:26 ` Andrey Borzenkov
2013-02-19 10:54   ` Martin Wilck
2013-05-03  5:01 ` Andrey Borzenkov
2013-05-03  8:21   ` Martin Wilck
2013-05-03 19:21     ` Dr. Tilmann Bubeck [this message]
  -- strict thread matches above, loose matches on Subject: below --
2013-02-10  0:17 Chris Murphy
2013-02-10  4:45 ` Theodore Ts'o
2013-02-11 15:38 ` Eric Sandeen
2013-02-07 10:18 Martin Wilck
2013-02-07 13:27 ` Jan Kara
2013-02-07 15:50 ` Eric Sandeen
2013-02-07 20:53 ` Theodore Ts'o
2013-02-08 10:15   ` Martin Wilck

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=51840E4B.1010807@reinform.de \
    --to=t.bubeck@reinform.de \
    --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.