RE: Encrypted Swap

David Christensen (David_Christensen@Phoenix.com)
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/