Respecting the Host Protected Area

[Phillip Susi]

Digging up an old subject here, but it seemed this thread ended before 
with the conclusion that the HPA would remain ignored by default in 
Ubuntu, so I marked the related bugs as WONTFIX.  I have received a new 
bug ( #254923 ) related to this issue recently and the user reports that 
the issue goes away when they test the 8.10 Alpha 4.  It appears that 
this policy has been changed in the Alpha because his dmesg shows that 
the kernel detects the HPA and does NOT unlock it.

I was wondering if this change was intentional, or accidental, and 
whether I should mark the other related bug reports as fixed instead of 
wontfix.

Ben Collins wrote:
> Without that patch, HPA could not be ignored at all. We defaulted it to
> ignore HPA because that fixed a lot of users. Most people wanted to
> ignore it anyway, since it is pretty legacy, and in a lot of cases it
> was only meant to trick old BIOS's into using larger disks.
> 
> Also, HPA is not enforced by the BIOS, but by the harddrive itself, so
> the BIOS could never decide to protect a portion of the disk. I've never
> seen cases where the BIOS requires info to be stored on the disk
> (perhaps in some very proprietary systems, but not normal x86 machines).
> 
> Fewer and fewer disks are using this. It used to be a way for OEM's to
> protect recovery and diagnostic tools, but given the easy and frequent
> replacement of harddrives, having these tools on a disk is becoming less
> and less common, and protecting them with HPA, even less so.
> 
>>From my understanding, HPA is close to being a legacy type feature. This
> is the first time I've heard of someone being affected by the alternate
> issue (ignoring it when it needs to be honored), but we had literally
> dozens of people sub'd to the bug where not ignoring HPA was causing
> them problems. It was actually an RC bug. We couldn't release Gutsy
> without this "feature".
> 
> The person in that bug report can very easily set the HPA to be honored,
> and be on their way.
>