On 10.12.2013 01:11, Chris Murphy wrote: > > On Dec 9, 2013, at 8:54 AM, Vladimir 'φ-coder/phcoder' Serbinenko > <phco...@gmail.com> wrote: > >> On 09.12.2013 16:28, Phillip Susi wrote: >>> On 10/23/2013 9:49 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote: >>>> partmap module is size-critical and CRC32 verification is pretty >>>> big. There are 3 problems with backup header: >>> >>> The grub core no longer fits in 63 sectors in all but the most trivial >>> configurations as it is, >> Not true. I've checked: all configs not involving compressed fs or >> diskfilter fit in 31K. >>> and a 2048 sector embed area has been >>> standard now for several years, so I don't think size is a problem. >>> >> We're speaking abut GPT, nothing to do with MBR embed area. >> >> My problem with that is that it increases complexity a lot in currently >> simple code. >> And also I had experience with backup header out of place due to disk >> reconfiguration and primary header corrupted but still well enough to >> have valid partitions. I could boot this system by using "gpt" linux >> option. With proposed changes this system would become unbootable. > > Technically if the alternate is invalid by being in the wrong location > (either end of disk or where the primary header says it should be located), > and the header is also invalid because the header is corrupt, then the disk > has an invalid GPT. So long as GRUB knows a valid MBR without an 0xEE entry > means any found GPT is stale (or rather, simply doesn't go looking for the > GPT), it seems possibly reasonable for GRUB to blindly use the primary > partition table. If it fails, it fails, even if it's unfortunate there's no > fallback to a valid alternate GPT. It's already the case. Probably the real remaining points are: - Should we use backup headers under some conditions? - Should msdos partitions be visible? Always? When it's not a PMBR? Or when GPT is corrupt? > > Maybe someone could argue it's a security problem for an invalid GPT being > used despite being invalid? > CRC32 isn't a MAC. Anyone who can modify GPT can fix CRC32 as well. > Also, I have some evidence that newer Apple EFI firmware are repairing these > cases. I have one older computer that I can consistently corrupt, and it > remains corrupted through boot, even to the degree the (linux) kernel face > plants by default if the primary header or table is corrupt, unless the gpt > kernel parameter is used. Yet a newer computer boots without the kernel > complaining, and upon startup completion the GPT is fixed. Identically > performed installations were performed in those cases. > > So maybe it can be argued the firmware has a role to play in fixing up GPT? > Or maybe this is a hideously bad idea for firmware, which as we know is > slightly less than massively bug ridden, to have such write privileges to the > disk. > Firmware writing to disk without being explicitly asked for it is a bugware or spyware. > > Chris Murphy > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
