One thing that encryption in the bootstrap CAN do is prevent Trojan attacks against the kernel image. If attackers can't find out what the encryption key is they can't create a substitute Trojan kernel. It plugs a hole.
Alan Mimms, Senior Architect F5 Networks, Inc. Spokane Development Center Liberty Lake, Washington v: 509-343-3524 f: 509-343-3501
-----Original Message----- From: SONE Takeshi [mailto:ts1@tsn.or.jp] Sent: Wednesday, October 22, 2003 2:18 AM To: Evan Langlois Cc: linuxbios@clustermatic.org Subject: Re: AMD64: Something's missing?
On Tue, Oct 21, 2003 at 10:26:01PM +0200, Evan Langlois wrote:
EtherBoot can boot lots of things from the network or an IDE hard
disk.
FILO can boot from IDE hard disk, IDE CDROM, floppy, and maybe more?
9load
I don't know much about except that it is used to load the plan9
kernel.
I don't know much about FILO. Can anyone comment on its compatibility
with
the LILO graphical features (displaying graphical menus/splash
screens), and
is there any support available for encrypted filesystems?
FILO is not aimed at being compatible with LILO.
Assuming FILO works like LILO, and doesn't know about filesystems, I'm
assuming encryption would be difficult, and it might therefore be best
to
chain-load another boot-loader, but I'd want the encryption keys to be
in the
ROM to make it as difficult as possible to get to them.
FILO has filesystem routines borrowed from GRUB, so it works like GRUB rather than LILO.
Encryption in the BIOS itself may be a positive feature, not just for corporate users that want to protect their IP, but laptop users and
such (in
which case the key would be asked for on boot) that don't want
sensitive
information leaking out just because a laptop was stolen.
Encryption in boot process doesn't make sense to me. What you want to protect is the data in the storage, not the boot image (kernel). Encryption of the storage is OS's bussiness, and the OS will ask you the password before decrypting any data.