[Brian - sorry for the off-list mail; I didn't notice you copied in tech-kern until I got my copy of the list message!]
> What does your support do? Does it let you write over the host > protected area? Does it let you extract what's in there? Yes and yes. It simply removes the protection, letting the host see the HPA as what it really is: more space appended to the space advertised to HPA-unaware software. As my sample dmesg said, >> wd0: effective capacity raised from 18039071 to 18041184 and then the subsequent auto-sizing saw the higher limit: >> wd0: 8809 MB, 17898 cyl, 16 head, 63 sec, 512 bytes/sect x 18041184 sectors > Sorry for the silly questions, but I'm not sure what this support > buys you. It sounds great, but I'm not sure what I'd get by making > this work in 5.x or beyond? Well, I now have it in 5.2 myself. (Change 4.0.1 in that git repo name to 5.2 to get that version. And, for anyone who's looking at the 4.0.1 version, I made a 32-bit mistake which needed fixing; look also at commits after the ones I named and read the commit messages to find all the ones you need.) I'm not sure this is a good idea in its current form. It works, in that it raises the soft limit to equal the hard limit - but that makes it really easy to overwrite supposedly-protected disk by mistake. It's true that overwriting important data is - and has always been - a "don't do that, then" mistake, and Unix has run on a "don't prevent stupid things because that also prevents clever things" philosophy, but this does make it significantly easier to corrupt presumably-important data by mistake. I'm wondering if it would be better to present the HPA as some kind of secondary device, with the soft limit raised only long enough to access it, then lowered back again once the HPA accesses are done. It would make the HPA slower to access, but it would also make it safer. Another issue with what I've done is also related to leaving the limit raised. According to the documentation I've been working from, on "power-on or hardware reset", the soft limit is reset to the hard limit. I know I've been changing the soft limit because it does revert to what it used to be on power-cycle. But a reboot does not cause it to revert; apparently whatever reset is done during a reboot on my test machine isn't hard enough to provoke that change. Presumably it's not the only such machine, too. There's one other interesting thing I noticed, and for this I need a brief bit of background explanation. When I get a "new" disk, one of the first things I od often (almost always, when it's second-hand and thus likely has someone else's data on it) is a write-read-compare pass over the whole drive. I have a program I wrote when playing with RAIDframe, designed to detect issues leading to two conceptual sectors ending up on the same real sector: it writes data to the whole disk such that each sector's data uniquely identifies the sector. On reading and comparing, I can then notice multiple conceptual sectors ending up in the same real sector. On a real disk that's not likely, but it _is_ an effective wipe (for the sort of threat model appropriate to me, at least). This is relevant because, when I took my test disk and read the 2113-sector HPA on it, I found my test pattern in many of the sectors. The only explanation I've come up with is that I did a wipe when I first got it, then put it in a machine whose BIOS used an HPA to stash stuff, but didn't overwrite the whole HPA. (Possibly multiple such machines, even, based on some strings I found in the HPA, with the disk, probably, effectively slowly shrinking as I move it between machines.) One thing I do not have is any way to change the hard limit. Since I can change the soft limit, I have little doubt I could change the hard limit if I wanted, presumably in response to an ioctl or some such, but I haven't bothered. (It's not something to do casually. According to the doc, the device shall not accept an attempt to change the hard limit if a previous change to the hard limit has been made since the last power-on reset.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
