Bug#491376: recipe for BIOS-based boot on gpt
On Sat, Aug 09, 2008 at 10:17:34PM +0200, Frans Pop wrote:
>
> 1) The use-case is insufficiently clear
>
> The reason _why_ a separate partition is required at all has (at least for
> me) not been sufficiently explained. So far my impression is that all
> this is just one huge ugly hack needed when GPT and some otherwise
> undefined "BIOS-based bootloader" are combined, but I have no idea yet
> for which type of systems that would be.
> I may be completely wrong, but it's up to the submitter to provide
> sufficient information. Instead we only get hackish patches without the
> context.
The whole purpose of this is solving a problem (whose technical details I
have explained in #488111), that will affect all users who install Debian on
standard PCs in the near future, when disks get bigger.
You can reproduce it very easily. So please don't take it for granted; go
ahead and try it.
Create a disk image that is 10 GB in size:
$ qemu-img create -f qcow debian.img 10GB
Install the latest daily build on it. Once finished, issue these commands
in the guest OS:
# cp -a /boot/grub /tmp/
# shred /boot/grub/*
# rm -rf /boot/grub
# mv /tmp/grub /boot/
Then reboot. Everything is fine (either with GRUB Legacy or GRUB 2).
Now try again with a bigger disk, make it 3 TB in size:
$ qemu-img create -f qcow debian.img 3000GB
Install the latest daily build on it. Once finished, issue these commands
in the guest OS:
# cp -a /boot/grub /tmp/
# shred /boot/grub/*
# rm -rf /boot/grub
# mv /tmp/grub /boot/
Then reboot. Results now depend on which kind of random code shred
generated, since after the MBR this is what your cpu is executing.
Of course, this is just a quick way of reproducing it; you don't need to
call shred to break it. It affects a variety of situations, for example
when you restore your whole filesystem from backup.
Here's a nastier variant. Suppose a local unprivileged user tricks the
administrator to remove /boot/grub/core.img, or archieves the removal of
that file by any other means.
Now it's relatively easy to execute arbitrary code with bootloader privileges.
All the attacker has to do is create a huge file (or lots of small files) to
populate all/most unused sectors with a 512 byte chunk of mallicious code.
Chances that the first core.img sector will be overwritten are very high
(in 512 bytes it is difficult to perform privilege scalation, but the code
to fill the disk with zeroes would fit).
Overall, the result is that the boot process is less robust (and for no good
reason).
> Because x86 is essentially the "reference arch" for D-I any implementation
> that adds a separate bootloader partition should
> - define 100% exactly when it is needed
Whenever you combine the following ingredients in your Debian install:
- A standard x86 PC
- GPT
- GRUB
> - ensure it is created *only* in that use-case
My last patch does that; except for GRUB, but then again there's no way to
tell at the partitioning stage if user will want to use LILO.
> All patches proposed so far fail these criteria in one way or another. It
> seems to me that all of them can result in the extra partition getting
> created when it is not actually needed.
I assume that you were thinking this is a very specific use case, but as I
explained above it is in fact a very general one.
> According to an earlier mail this BR is somehow related to #488111.
> However, nowhere in the patches proposed so far do I see the BIOS boot
> partition flag getting set.
They all have something like this in one place or another:
+ open_dialog SET_FLAGS $id
+ write_line "$flags"
+ write_line bios_grub
+ write_line NO_MORE
+ close_dialog
> If the flag and this partition _are_ related then partman should ensure
> that the BIOS boot partition flag can only be set on a BIOS boot
> partition and not on any random other partition.
There's no "flag". This is just the way Parted exports it to the upper
layer. For example, if you set the boot "flag" in a GPT partition, you get
an EFI partition type.
> If the BIOS boot partition needs to be a separate partition because its
> usage means any file system data could get overwritten, then partman
> should ensure that such a partition cannot be used for a file system. The
> current flag does not do that.
I'll fix that.
> My current feeling is that if it is demonstrated after that that a
> separate bootloader partition really is needed, it should either
> - be added based on the detection of a separate subarch (and thus
> *separate* recipes), or
It's not a subarch, as explained.
> - be added at runtime on top of a normal, clean recipe based on very
> specific and targeted tests (similar to the way a /boot partition is
> added automatically when LVM is used).
I did this already (Jérémy requested), except on buildtime.
Shall I move it to runtime?
> All in all, I doubt this is something that can be implemented _cleanly_ in
> time for Lenny.
Well, I sent the first patch in 19 Jul. Back then I thought it was good
timing. Today it's clear I should have sent it earlier.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
Reply to: