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. Eric 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. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
