On Fri, Nov 13, 2020 at 09:28:16PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> From 4bd2f59773bec11ad7be1ced5b49edbf44d711f2 Mon Sep 17 00:00:00 2001
> From: Vladimir Serbinenko <phco...@gmail.com>
> Date: Tue, 10 Nov 2020 20:23:56 +0100
> Subject: [PATCH 2/2] Document new limitations on MBR gap support
>
> Signed-off-by: Vladimir Serbinenko <phco...@gmail.com>
Reviewed-by: Daniel Kiper <daniel.ki...@oracle.com>
This is last chance to complain! I am going to take this patch next week...
Daniel
> ---
> docs/grub.texi | 43 ++++++++++++++++++++++++++++++++-----------
> 1 file changed, 32 insertions(+), 11 deletions(-)
>
> diff --git a/docs/grub.texi b/docs/grub.texi
> index 37f7ce7da..d6ce0999f 100644
> --- a/docs/grub.texi
> +++ b/docs/grub.texi
> @@ -829,25 +829,46 @@ four primary partitions and additional logical
> partitions. With this
> partition table format, there are two ways to install GRUB: it can be
> embedded in the area between the MBR and the first partition (called by
> various names, such as the "boot track", "MBR gap", or "embedding area", and
> -which is usually at least 31 KiB), or the core image can be installed in a
> +which is usually at least 1000 KiB), or the core image can be installed in a
> file system and a list of the blocks that make it up can be stored in the
> first sector of that partition.
>
> -Each of these has different problems. There is no way to reserve space in
> +Modern tools usually leave MBR gap of at least 1023 KiB. This amount is
> +sufficient to cover most configurations. Hence this value is recommended
> +by the GRUB team.
> +
> +Historically many tools left only 31 KiB of space. This is not enough to
> +parse reliably difficult structures like btrfs, zfs, raid or lvm, or to
> +use difficult disk access methods like ahci. Hence GRUB will warn if
> attempted
> +to install into small MBR gap except in a small number of configurations
> +that were grandfathered. The grandfathered config must:
> +
> +* use biosdisk as disk access module for @file{/boot}
> +* not use any additional partition maps to access @file{/boot}
> +* @file{/boot} must be on one of following filesystems:
> + * AFFS, AFS, BFS, cpio, newc, odc, ext2/3/4, FAT, exFAT,
> + F2FS, HFS, uncompressed HFS+, ISO9660, JFS, Minix, Minix2, Minix3, NILFS2,
> + NTFS, REISERFS, ROMFS, SFS, tar, UDF, UFS1, UFS2, XFS
> +
> +MBR gap has few technical problems. There is no way to reserve space in
> the embedding area with complete safety, and some proprietary software is
> known to use it to make it difficult for users to work around licensing
> -restrictions; and systems are sometimes partitioned without leaving enough
> -space before the first partition. On the other hand, installing to a
> -filesystem means that GRUB is vulnerable to its blocks being moved around by
> -filesystem features such as tail packing, or even by aggressive fsck
> -implementations, so this approach is quite fragile; and this approach can
> -only be used if the @file{/boot} filesystem is on the same disk that the
> -BIOS boots from, so that GRUB does not have to rely on guessing BIOS drive
> -numbers.
> +restrictions. GRUB works it around by detecting sectors by other software and
> +avoiding them and protecting its own sectors using Reed-Solomon encoding.
> +
> +GRUB team recommends having MBR gap of at least 1000 KiB
> +
> +Should it be not possible GRUB has support for a fallback solution which is
> +heavily recommended against. Installing to a filesystem means that GRUB is
> +vulnerable to its blocks being moved around by filesystem features such as
> +tail packing, or even by aggressive fsck implementations, so this approach
> +is quite fragile; and this approach can only be used if the @file{/boot}
> +filesystem is on the same disk that the BIOS boots from, so that GRUB does
> +not have to rely on guessing BIOS drive numbers.
>
> The GRUB development team generally recommends embedding GRUB before the
> first partition, unless you have special requirements. You must ensure that
> -the first partition starts at least 31 KiB (63 sectors) from the start of
> +the first partition starts at least 1000 KiB (2000 sectors) from the start of
> the disk; on modern disks, it is often a performance advantage to align
> partitions on larger boundaries anyway, so the first partition might start 1
> MiB from the start of the disk.
> --
> 2.20.1
>
>
> --
> Regards
> Vladimir 'phcoder' Serbinenko
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
