[LinuxBIOS] Adding Support for ATA Freeze Command.
ralph at inputplus.co.uk
Sat May 21 17:26:01 CEST 2005
> On Sat, May 21, 2005 at 10:43:42AM +0100, Ralph Corderoy wrote:
> > Are people generally aware of the ATA security commands?
> No, probably not. Certainly not if people means everyone with a ATA
No, sorry, I meant people on the list.
> > Once a drive's locked with an unknown user password then it's a dead
> > drive unless the manufacturer can be persuade to give you the higher
> > level password that allows a security format of the device to be
> > done. This normally requires a paper-chase to prove you're the
> > rightful owner.
> I can see at least two other ways to recover the drive;
> 1. Find that higher level password from someone other than the
The manufacturer tends to set it to something unique and keeps a record
of it against the unit's serial number.
> 2. Build custom hardware or just a custom BIOS to do a brute force
> search for the password in the drive.
After five failed attempts the drive refuses to do anything more until a
hardware reset or power cycle. Custom hardware could do the reset but I
don't know if it's within the ability of a BIOS?
I am aware that someone in the UK has built hardware that can
brute-force it in under 12 hours.
> > It LinuxBIOS were to add support for Freeze drives it would be
> > another advantage over other BIOSes. Am I right in thinking that
> > LinuxBIOS itself knows nothing about ATA and that's left to FILO?
> LinuxBIOS initializes the chipset and the payload may use the chipset
> to speak to a disk.
Right. So it's not LinuxBIOS itself that would be involved.
> > Is that the only payload that deals with ATA?
> No, I know of a few other; Etherboot, Linux, ADLO and the FreeBSD
> kernel if we got that booted, I don't remember.
> I'm not sure this functionality really belongs in the init part of
No, I don't think it does unless there's already ATA commands in there
that talk to a drive.
> but perhaps you could have it added to Linux if it isn't already
> available there through ioctl() calls.
It's possible in Linux already at the system call level, and recently
hdparm added support through its -F option -- the c't article's author
sent a patch IIRC, but by the time Linux is running is a bit late. A
malicious program running under Linux where Freeze has already been done
by hdparm could write to the MBR causing the password to be set on the
next boot. That's unless the BIOS has done a Freeze before the MBR gets
> There's a problem with the interaction required, LinuxBIOS has always
> been designed to not require any configuration or options to be
> handled interactively, which I think is good. Others will of course
> disagree. :)
It does need an element of configuration else the drive would always be
frozen and the password could never be set. It sounds like FILO could
be the place. Is that the standard `boot from a hard drive' payload
More information about the coreboot