# Message: 2
# From: Eric Auer <[EMAIL PROTECTED]>
# Date: Thu, 14 Apr 2005 12:54:51 +0200 (MEST)
# To: freedos-user@lists.sourceforge.net
# Subject: [Freedos-user] Re: Methods against harddisk password troubles
# Reply-To: freedos-user@lists.sourceforge.net
#
# 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.
I would be *extremely* surprised if this was ever a hard reset, because
as noted earlier, there's not a standardized way to perform such a
reset - and in fact nearly every ATA controller chip on the market
provides absolutely no way to do it. There would have to be extra
hardware between the controller chipset and the connector on the
mainboard. IOW, if the spec for some reason required a hard reset,
the capability for it would exist in the controllers because the
industry would demand it ("what?! you want us to add components, just
so that we can meet some stupid spec?!?")
# 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.
No, that's not how it works. If there's a password set, then security
is enabled. What you're describing is basically what Security Freeze
is meant to accomplish (but it's at the BIOS level, not the drive
level). The BIOS should contain a switch for "security mode frozen",
preferably enabled by default. In the BIOS, you can set a password
because the Freeze command hasn't been issued yet. Perhaps three
settings for the switch, "On (default)", "Off (this boot), and "Off"?
# 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.
Yep.
# 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 :-|.
And, that's the problem: that's where it really belongs.
It's as if a carpenter building a house simply didn't bother to buy
the tools to do the job right, even though the hardware store sells
them: it's really not the HW store's fault...
# 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.
You're exactly right - which is why it doesn't work that way.
# 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 ;-).
Yeah, I realized that last about five seconds after I hit "send" :-P
-------------------------------------------------------
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_ide95&alloc_id396&op=click
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
