Re: Sending ATA commands?

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

        Hello.  In thinking about your 
implementation, I wonder if you could attach the HPA area as an additional
partition on the default disklabel, or, if the disk is gpt partitioned,
fake up another partition in the gpt table.  In any case, I  think I would
be  most comfortable with an implementation which set the HPA area as
read-only and only became read-write through some user command, perhaps a
new command for atactl(8).  I realize that from a hardware perspective, you
may not be able to set read-only on the HPA once you enable access to it,
but I imagine you could set that restriction in the wd(4) driver.  That
isn't full proof, as you could probably write a program to use the same
interface as atactl(8) does to get around the restriction, but it would at
least protect you from doing something catastrophic through dd(8)
confusion or from a newfs typo.
        Have you found any BIOS's that can use this HPA area to load saved
NetBSD rescue images as a way of restoring machines who's disks have been
corrupted?
-Brian

On Aug 11,  7:19pm, Mouse wrote:
} Subject: 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
>-- End of excerpt from Mouse