DRAM data persistence

On a sunny day (7 Jul 2007 10:05:44 GMT) it happened Jasen Betts wrote in :

See other posts how it really works, somebody showed some kernel code. Writing to RAM would spell disaster in any system with memory mapped IO. It would also increase power consumption.

But it is still not a good idea in a modern OS that needs to go fast. You are better off making the application clear the memory that has secret data. This way every malloc() won't cause a long delay. Some RTOSes can be said to be modern.

There are two aspects to this. One is the overflow itself, which is an application error. The other one is the common practice to place malicious code on the stack for execution.

The OS can't protect against the former but can protect against the later (vanilla Linux doesn't).

Here is an example of calling an arbitrary function via a stack variable overflow:

#include

void evil(void) { printf("evil\\n"); }

void good(int overflow) { void *x=NULL;

if (overflow) { /* Overflow x to redirect the return */ *(&x+2)=(void *)evil; }

printf("good\\n"); }

int main(void) { printf("main_start\\n"); good(1); printf("main_end\\n"); return 0; }

$ a.out main_start good evil Segmentation fault

It causes a segfault, after the damage is done. It could be avoided by using assembly.

Kind regards,

Iwo

Nope, but like 20 years ago we found a program for the IBM PC which allowed you to set the memory refresh rate, so we were fooling around to see how long the memory could hold data without being refreshed, and we were amazed to see it was on the order of a few seconds.

Yes, indeed. If you load an application like MS Word, the PC XT will last forever with the DRAM refresh switched complelely off. The CPU cycling around is enough to refresh the memory. If you quit to the MS DOS prompt, it will hang up in 2...3 seconds.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

Nice... reminds me of the Apple II and -- I think -- the Sinclair ZX-81 that arranged video memory such that the regular video display cycled through all the DRAM rows needed to perform a refresh. Clever...

The original PC had one of the DMA channels do reads to the address space. It cost a little performance but saved a bunch of $$.

In the '80s I built what amounted to a huge logic analyzer to capture ATE traces to process off-line. The DRAM refresh logic was driven by essentially a retriggerable monostable. If a write or read didn't happen in a given time the refresh logic would insert one. If the monostable never fired, no problem, the memory didn't need refresh cycles.

You might be able to set a 'sticky bit' to prevent a secure process from swapping out. If it (or at least its data pages) are not swapped out, one need only wory about a RAM image.

One could trap kill and sleep signals and overwrite the RAM image to prevent snooping around in a flash drive or disk image of a suspended system.

Bumper sticker: Free the Mallocs!

That was back when the DRAM real estate could hold a pretty good charge. I'll bet its a lot less with modern memory technologies.

The ZX-81 also ran code at the end of every line. The code jumped to the display ORed with 0x8000. Circuits made the op-codes into NOPs as they went to the Z80. The last character of the line was a HALT instruction which was let through. The refresh register served as a counter that interrupted after the line was complete. When the interrupt happened, the code set it up for the next line. The combination of the display addresses, the refresh register and the code hit all the addresses.

I had a video card like that, there were problems:

X windows likes to cache fonts in off-screen locations.

not such a good idea.... after an hour or two the font would have bad bit-rot. it had the same problem if I used a virtual display larger than the raster.

a case of "out of sight, out of mind".

The display on the ZX81 was done using software and consumed 3/4 of the processors time, I don't think the display was involved in the refresh,

Also the Z80 processor had inbuilt refresh hardware (controlled by the 7 bit 'R' register)

one of the index registers (IX or IY) held the location of the font I saw a demo where someone had made their own custom font... but back then I didn't understand how to hand-assemble the multi-byte op-codes needed to manipulate those registers.

Bye. Jasen

On a sunny day (10 Jul 2007 11:42:14 GMT) it happened Jasen Betts wrote in :

There was a big chip that had the pixel shift register and some other stuff in it. It used to overheat too, I returned one of my ZX81 for guarantee, after I soldered in an 48 pin DIL IC socket for that chip. Added a note: Please replace chip. Never a complaint, just got it back fixed.... for free. Probably saved their service department time. The ZX80 was pretty much teh same as teh ZX81, here yo ucan see the diagram: (bottom right).

I have used that register as a "random" number generator. It works fine when triggered by a human event such as a keyboard stroke, but reading the register in a tight loop leads to predictable predictability.

it

We did a DRAM refresh circuit for an 80186 CPU board by swapping the "row" and "column" address connections to the memory. That way 256 consecutive reads of program ROM would provide a complete refresh. Unfortunately, real code does not always behave in a way tht would guarantee hitting every "row" in time, so we were forced to add a timed interrupt call to a routine consisting of 256 consecutive NOPs.

it

I believe you misread what you saw. It wasn't the IX or IY. It was the "I" register. The interrup vector register is put on the upper 8 bits of the bus while the refresh register is put on the lower 8. They combined this with the row and the character to form the font address.

The ZX81 did not use the display accesses to refresh DRAM.

You could turn the display off (FAST mode) and it would still run.

It was up to the DRAM pack designer to manage refresh, e.g. by using the Z80's internal 7-bit refresh row counter or an external counter like the

The BBC micro certainly did use the display accesses to refresh DRAM.

It is surprisingly easy to refresh DRAM on 6502 systems, once you know how:

Other posters have expressed surprise at how long some systems would run without refresh before crashing. I suspect that's a red herring. Refresh times are in the order of milliseconds, I doubt this can be stretched a thousand fold. More likely that the system software RAM accesses provide refreshing for a few seconds right up to the point where it fails to refresh one particular row often enough and the system fails.

IIRC the first DRAMs had a 1 to 4 millisecond refresh period.

Later DRAMs had to increase that to 64 milliseconds because they had a lot more rows to refresh and wanted to keep the row strobe rate from going up.

E.g.

The size of the charge is not that important; modern memories use less charge per memory cell and are holding it for much longer. So they are objectively better than older 'leakier' DRAM cells.

This is not completely true. When the ZX81 was in fast mode the Z80's refresh register would be doing the refresh actions but in slow mode, the refresh register was reloaded at the start of each line and never went through the entire 8 bit range. The instruction fetches filled in the rest of the values. If you allowed the instruction fetches to cycle the RAS control even if the address was within the ROM, the DRAM would get refreshed.

how: