[LinuxBIOS] Adding Support for ATA Freeze Command.

Peter Stuge stuge-linuxbios at cdy.org
Mon May 23 20:41:48 CEST 2005


Hi again Ralph,

On Mon, May 23, 2005 at 06:13:32PM +0100, Ralph Corderoy wrote:
> > My humble opinion is that you have much bigger problems if a malicious
> > program has root priviledges in your system.
> > 
> > Sure, if a security "hole" is easy to plug, why not plug it, but there
> > are many other security measures that can and should be used on
> > production systems with important data that are effective for
> > recovering from an attack of this kind as well as several others.
> > (Redundant hardware and storage, with external backups.)
> 
> A scenario:  I have daily backups, I carry out a post-mortem after
> detecting an intrusion, I'm happy to re-install from scratch and restore
> a known-safe backup, and fix the entry point of the cracker before
> exposing the machine to the network.  But the hard drive is now for the
> bin because it's been locked.
> 
> I'm happy to take all those other precautions, but I'm trying to cut out
> one of the few things a malicious, remote, cracker could do that costs
> me hardware.

Right, no redundant storage, which probably wouldn't be susceptible
to the problem anyway since the security commands only work with ATA
and S-ATA drives.

I know I wouldn't care much about the ATA drive if I was prepared to
deal with downtime and labor required for forensics and recovery in
the above scenario.


> > Then, suddenly, the Linux kernel isn't so late in the boot process.
> > Remember, LinuxBIOS doesn't care about legacy junk such as the MBR, it
> > starts the payload immediately, as per compile-time configuration.
> 
> I agree if the Linux kernel is very early on, i.e. the BIOS stage,
> then it's good enough for the kernel to do it.  I was talking about
> the OS once started by the bootloader.

With Linux as the payload, the OS is the bootloader. :)


> But wouldn't that require a run-time option again because you'd
> want to avoid the freeze happening some times, and without flashing
> a new BIOS.

Right. And the option can't be accessible by root.


> It's far easier and more portable to write the MBR than it is the
> BIOS. Given root access will sometimes be obtained I'd like to stop
> them being able to make my hard drive defunct;  its data I've got
> backed up, offline.  It's all a trade-off but it would seem that
> adding an ATA Freeze most of the time on start-up is a worthwhile
> one.

"more difficult and less portable" is not "secure" - I would argue
quite the opposite; it's security by obscurity, and that's always a
bad idea.

But sure, if you want to protect the BIOS from software run as root,
use real ROM (not flash). And if you want to protect the ATA drive
from being locked by root, have the software in ROM send a freeze
command.

Question is, should LinuxBIOS really go about changing configuration
and settings of the hardware beyond what is absolutely neccessary for
the payload to function?

I'm not sure it should, I think it's better to put the freeze command
in FILO or Linux or 9load or ADLO or whatever payload.

>From a security point of view it doesn't matter since the LinuxBIOS
init code and payload are stored in the same place and if the payload
can be changed the init code can be changed too.


//Peter




More information about the coreboot mailing list