Re: Check if device is bootable
Posted: Fri Nov 13, 2015 3:29 am
Even if the use of those 4 bytes for a signature is optional, the standard has never said that they can be used for boot code, even the 2.0/2.1 versions of the standard say that the boot code is 440 bytes. If you decide you don't want to use a field, that doesn't give you permission to overwrite it with something else.Brendan wrote:
Do you understand the difference between "may" and "must"?
This may be used by the OS to identify the disk (but it's still perfectly legal for the OS to use it for executable MBR code instead).
It doesn't break any compatibility. Using those 4 byte for boot code was always against the spec. MS-DOS 1.0 didn't even support hard drives (or even 3.5" floppies, so good luck running it on a modern system), so is utterly irrelevant. Ancient OSs (that do support hard drives) are almost certainly already incompatible with modern UEFI-based systems due to their lack of LBA addressing support. All of that is besides the point anyway, because the "de-facto" Microsoft/IBM MBR specification included the signature and any OS/bootloader that abused those 4 bytes was always violating the spec.Brendan wrote:"PC compatible" computers are full of backward compatibility for very good reasons. Breaking backward compatibility (and breaking all older OSs that complied with previous versions of a specification) is almost never acceptable. Don't forget that most computers that come with UEFI also have a BIOS compatibility layer and that hybrid "MBR + GPT" is entirely possible; and nothing prevents you from running (e.g.) DOS 1.0 from 1981 on a UEFI system purchased last week.
Clearly you've never actually tried that... That doesn't happen.Brendan wrote: It's very much a problem if you install 2 different versions of Windows (e.g. Win7 and Win10) in separate partitions and they both fail to keep track of which disk is what because they're constantly trashing each other's disk signatures.
What exactly that feature did depended on the BIOS. Systems I'm aware of stored a checksum in their configuration memory (Flash/CMOS) and alerted the user on boot if it changed. They obviously only considered the first 440 bytes.Brendan wrote:It has nothing to do with the virus protection features of 1990s BIOSs which did none of this any only prevented writes to the MBR.
So the act of installing Windows will change the checksum anyway, since it will modify the partition table. Quibbling over the 4-byte signature is therefore rather stupid.Brendan wrote: The firmware (not me) "measures" the entire sector. It makes no difference if it's executable or not. Please note that other data (e.g. ACPI tables, etc) is also measured (by firmware, not me).
The specifications say "the OS", not "Brendan's OS". I agree that it's vague, but it could easily be interpreted to mean "the last/current OS booted". Your assertion that it has to mean "your OS" or maybe "the first OS installed" is without suppport.Brendan wrote: UEFI specs say that "the OS" (my OS) may use those bytes. If any other OS that is not "the OS" (e.g. Windows) modifies those bytes then it's a malicious violation.
The spec is the spec whether you agree with it or not. Your philosophical beliefs about the MBR are not supported by it. If you want to invent your own computing platform with a different spec, go ahead. The fact that it says that "may be used by the OS" and unambiguously says that the boot code is only 440 bytes makes it pretty clear that those 4 bytes cannot be "claimed" by any bootloader for its own use.Brendan wrote: Of course (as I've already said) the MBR shouldn't belong to any specific OS. An OS only "owns" data in its partitions and has no right to modify any part of any disk outside of its own partitions unless it has the computer owner's consent. If UEFI specs says otherwise then the UEFI specs are wrong (but they don't, they only say "optional" or "may" and never say "must").