tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Sending ATA commands?



[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                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index