ATA security commands, bug in atacontrol

ALeine aleine at austrosearch.net
Mon Apr 4 16:03:50 PDT 2005


craig at tobuj.gank.org wrote: 

> Um, wouldn't setting the password on a system in which the BIOS
> offers no ATA security support render the system unbootable? The BIOS
> would be unable to read the boot sector without first unlocking the
> disk...

Correct, if BIOS is configured to try to boot only off the drive you
just password protected. The feature I proposed is not meant to be a
replacement for the kind of functionality that should be provided
by BIOS, it's meant to provide a way to issue ATA security
{set,unlock,disable} password and other commands to drives other
than the bootable drive from FreeBSD. For example, imagine that you
are about to go on vacation and you want to set the password on the
drives that will stay in your home unsupervised. You could then boot
FreeBSD into single user mode from a USB flash drive (with the
appropriate sysctl variable set beforehand in loader.conf in order
to prevent FreeBSD from issuing the freeze lock command on startup)
and then set the password(s) on your hard disk drive(s). You would
then take the USB flash drive with you and after returning home you
would repeat the procedure (assuming your drives were not stolen :->),
only issuing unlock and disable password commands. Another reboot and
you could boot off your drive(s).

> Since compliant BIOSes have already frozen the config by the time
> the OS boots anyway, the only reason I can think of for atacontrol to
> have security support would be if you're booting from some other
> media, i.e. floppy, CDROM, network, USB...
> 
> It might also be somewhat useful for secondary (non-boot drives).
> *BUT* that would probably only work on machines where the BIOS doesn't
> freeze all the drives on startup.

A BIOS that has the ATA security features implemented correctly sends
the ATA security freeze lock command on drive identification, but such
a BIOS also provides a user interface to the ATA security settings, so
the feature I proposed is clearly not meant for such cases, the single
user mode requirement also makes it obvious it is not meant to be a
replacement for such BIOS functionality, but a workaround that prevents
potential abuse while also offering a limited way to issue AT security
commands. Most BIOS manufacturers (Award especially) are not likely to
do anything about this issue any time soon (if at all), so at the very
least FreeBSD should issue the freeze lock command if the feature I
described would not be seen as worthwhile.

ALeine
___________________________________________________________________
WebMail FREE http://mail.austrosearch.net 


More information about the freebsd-hackers mailing list