> 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).
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.
The BIOS procedure necessary to size RAM, and find out what sticks
are in what slots, is quite a memory-distructor itself. With SDRAM
controllers, after the reset, all memory addresses are ignored.
A write to memory writes to ALL memory plus the controller itself.
You typically set up the controller by writing some commands to
address 0. Once there is a power-up, the BIOS must delay at least
100 us before trying to initialize the SDRAM controller. The
"all banks precharge" command connects all banks together and
anything they contained is lost forever. This is the first command
necessary to initialize the SDRAM controller. All the command bits
are driven as 12 bits and they are sinked by every cell on every
chip because the all-banks precharge hooked them together. So, even
if by some magic the cells had survived the power-cycle, the lowest
12 bits in every long-word will now be corrupted by the initialization
commands that follow.
The so-called "quick" memory test just doesn't test the memory which
typically involves setting/resetting/checking every bit in memory. The
initialiation, sizing and the zeroing still occurs.
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/