Hi Gordon, thanks for the info...

> The SECURITY FREEZE LOCK command shall set the device to Frozen
> mode.  After command completion any other commands that update the
> device Lock mode shall be command aborted.  Frozen mode shall be
> disabled by power-off or hardware reset [which you explain to be
> one which includes CPU reset]...

The Heise article writes that for example going to standby / suspend
triggers a reset at wakeup. I can confirm that as far as ACPI docs
have an opinion about it... The CPU has several sleep states, and in
the deeper ones, all state / register information is lost, so you
have to save it to RAM first, and the BIOS will jump to your wake-up
handler to let you restore it when the system wakes up. Note that e.g.
FDAPM does not support this, as you have many system programming and
exotic registers to save if you want to save ALL state of a modern CPU.
So FDAPM only supports light "stop CPU" sleeps and poweroff in ACPI,
the deeper suspend sleeps are only supported with APM BIOS help.

> It's not just the jumper itself; I/O lines
> into the ASIC have gotten to be at quite a premium.

You mean the pin-count of the main controller chip is the bottleneck?
In theory, you could add a normal CMOS logics chip or a PAL to encode
some of the more boring signals into a condensed / fewer bit version
first, but extra chips take extra PCB space and robot work (you need
an extra chip "tape" feeder, too).

Could you also add some explanation about the unlocking? Can I set a
key without implicitly locking the disk at the next boot? I mean, a
key which is just there and has to be provided before you can set the
locking mechanism to another key? That would avoid the "have to boot
from diskette to get access to the harddisk" problem of fully locking
the disk, and the "everybody can set a random key" at the same time.
Only remaining problem would be, unless I activate freeze state at boot,
that somebody might be able to activate the lock - with my key - w/o
having to know the key. Depends on how things are implemented. Still no
real problem, I could boot from diskette one time and reconfigure to
"key set but disk not locked" state. Again, IF such a key set but disk
not locking state exists.

About user / admin keys: I assume you need the user key to change the
user key and the admin key allows you to change both keys. I also assume
that you need the admin key to block the "admin key can override" thing.
So basically I can set an admin key only, and whenever some trojan / ...
messes with my user key, use the admin key to override. Of course it would
be really cool to have an user interface for all that in the BIOS rather
than having to boot from diskette :-|. Of course if the BIOS would store
the key in CMOS, it would again be trivial for a trojan to replace my key,
at least given that most people use one of the same few quasi-monopoly BIOS
brands. So the BIOS would provide me with a disk locking key prompt ideally.


PS: No need to CC me in the reply, I am on freedos-user anyway. And please
edit the subject to be "Methods against harddisk password troubles" instead
of the subject of the digest ;-).

SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
Freedos-user mailing list

Reply via email to