Re: Cryptoloop patch for builtin default passphrase
From: Bill Davidsen
Date: Tue Oct 26 2004 - 16:17:21 EST
Valdis.Kletnieks@xxxxxx wrote:
On Mon, 25 Oct 2004 19:23:35 BST, Paulo Marques said:
(why would you need confidential information to boot in the first place?)
The problem is not that the info in the NVRAM is "confidential",
but that most of it is "configuration".
Really sucks if you recable your SCSI controllers, the default boot disk
changes from controller 4, device 5, to controller 2, device 3 - and you
have to go and re-cable the OLD way, find the rescue CD, and fix /etc/fstab
so that you can boot in the same config that you installed the software?
Either that, or forever lose the use of "default boot device", and
have to specify it on every single boot if you want the software to work.
That *really* sucks if it's a rack-mount in a colo, you need to get physical
access to reboot....
No it is not. You would just type in again *if* the contents of nvram
got lost which shouldn't happen in the first place (or at least happen
rarely).
So you change IRQ9 from level to edge trigger, or change "default boot order"
from "floppy, cd, hard drive" to "floppy, cd, hard drive, network", and
suddenly your software evaporates?
That certainly violates the Principle of Least Surprise, and why I asked
if it was an intended effect.
It depends on the intent of the encryption. If the purpose is the
protect the data, then this is acceptable. In some cases it is more
important to protect the data than to preserve them.
More to the point, I thought there was a small section of nvram reserved
to local system use, which the BIOS should not change. The appropriate
manual is 100 miles away, I have no time to google. Beside which someone
will pop up with the answer before I could look ;-)
--
-bill davidsen (davidsen@xxxxxxx)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/