Messages in this thread | | | From | David Christensen <> | Subject | RE: Encrypted Swap | Date | Fri, 17 Aug 2001 10:10:24 -0700 |
| |
> > Ryan Mack proclaimed: > > > is running. If the system is physically compromised, > there is little way > > > I can think of to take root without having to at least reboot the > > > computer, thus destroying the unencrypted contents of RAM. > > > > This is a myth. RAM survives rebooting, even after a quick > power cycle > > most cells will probably still be ok. And with todays > memory sizes, it > > would take a noticable amount of time to initialize all of > it to a given > > value, so most systems don't do it (just testing some bytes of every > > megabyte instead). > > > > Holger > > - > > Errrm no. All BIOS that anybody would use write all memory found when > initializing the SDRAM controller. They need to because nothing, > refresh, precharge, (or if you've got it, parity/crc) will work > until every cell is exercised. A "warm-boot" is different. However, > if you hit the reset or the power switch, nothing in RAM survives.
Most modern firmware does NOT clear memory during POST, it takes too long. Certain compatibility areas are usually cleared (such as the 1st megabyte) but the rest is left as is, except for a few read/writes (usually on a megabyte boundary). The exception to this rule is ECC systems. They have to be written to make sure the ECC information is correct.
SDRAM memory sizing is usually done by reading an EEPROM on the SDRAM DIMM. The BIOS doesn't need to guess the correct timing values, it simply reads the EEPROM and programs the memory controller. In the case of a BIOS that doesn't use EEPROM you might lose data as the BIOS iteratively tries different memory timings and tests if they work.
I have done work implementing ACPI S3 (suspend-to-RAM) in DOS by simply hitting the RESET button and restoring the memory controller settings. The contents of RAM have always been valid.
David Christensen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |