Is FreeBSD violating EFI specification?

P

petrek

I think it does, but I would appreciate any comments on this before I will waste some developer's time ;) Here's a link to the specification:
http://www.intel.com/content/dam/www/public/us/en/zip/efi-110.zip

Currently in the FreeBSD's PMBR the end CHS address of the partition is always set to FFFFFF (it means the 256th head, first two bytes are head's address, and heads are counted from 0, so 0 would be the 1st head, FF = 255 is the 256th head), while disks due to historical reasons in most cases can have at most 255 heads, and FE address). From specification:
"Each MBR partition record must be checked to make sure that the partition that it defines physically resides on the disk" and little later: "If any of these checks fail, the MBR is not considered valid". Because of the above, the partition FreeBSD defines doesn't reside entirely on the disk, since there can be no 256th head on it, and the PMBR is not valid.

There is a defined case in the specification to set this value to FFFFFF:
Code: 
Set to match the Ending LBA of the EFI Partition structure.
Must be set to 0xFFFFFF [file]if it is not possible to represent the starting
LBA[/file]
But since it is possible to represent the starting LBA, and PMBR does this currently, this condition is not met.

There is another part where setting of all F's is mentioned:
Code: 
(PMBR) reserves the entire space used on the disk by the GPT partitions,
including all headers. [...] If the GPT partition is [file]larger than a partition that can
be represented by a legacy MBR[/file], values of all Fs must be used
Since EFI doesn't use CHS values at all, this can only apply to LBA's values. Legacy MBR can represent up to 2 TiB of storage. As a confirmation we can read in table 11-7 in "Size in LBA" record:
Code: 
Length of EFI Partition Head, 0xFFFFFFFF if this value overflows.
Indeed, FFFFFFFF*512 bytes equals 2 TiB (-512B). There is no other mention of all F's in the PMBR specification, so from all of the above, head address should be set at most to FE for all disks smaller than 2TiB, and now it isn't.

Am I missing or don't understand something here?
 
Is that specification up to date? It says 2002 on the front page and I would think there must have been some revisions to it after 2002.

I believe setting the end CHS to all 0xFF is in fact valid in case the end LBA can not be represented in CHS and that's what the spec is trying to say but there might be an error in the sentence you quoted.
 
Yes, it is up to date, at least in this area, there's an update to it, but it doesn't say anything about PMBR. This file is also mentioned here (the link is different, because Intel moved this file) as a reason for such setting.

I believe it's not valid for a few more reasons.
  1. The spec is saying exactly what I wrote for both start and end CHS values, and having so many years and interested parties someone would notice it and fix it if it was an error. What's more, FFFFFF is not working (or rather should say it behaves like a very vicious virus) in some cases. Also look number 3.
  2. Having both values set to valid (or not valid) values at the same time as is in the specification has much more sense. When you encounter a valid start CHS value, you expect the entire partition to be valid, otherwise it doesn't make any sense to set it in the first place, and it would create confusion and a lot of unneccesary code to deal with it, so the end value in such case must also be valid. If you want to say the partition is not valid, makes much more sense to set both values as invalid, in case some lazy setup will check only one value. Also number 3.
  3. As you can read in the bug report above, 0xFFFFFF makes some computers completely unbootable (confirmed on a few computers I have), and in some cases it means risking frying your disk to recover from it. Do you think Intel could write specification that would advise such behaviour and not be sued to death for it? I think this sentence:
    Code: 
    "Each MBR partition record must be checked to make sure that the partition that
it defines physically resides on the disk"
    is written exactly to avoid such situation, now maybe not so, but in 2002 a lot of computers had this issue. So when you set a valid start CHS address you define partition, so you need to make sure you set a valid end of that partition also.
  4. Other partitioning tools I used set it to FEFFFF, are they all wrong? I know it's not too valid argument, but still it shows their working interpretation, that is not contradictory with what said specification is saying ;)
 
You must log in or register to reply here.
Back
Top