OSDev.org

When starting the PC, memory is totally free.

Until the JMP to 0x7C00, A20 should never have been enabled.
So the memory over the first MB have never been used (and should be clean , then).

Because of this, if I load my kernel at the first MB, I shouldn't initialize each variable to 0, to be sure that they're clean. All the memory is already clean...

Right?

When a computer starts up, the RAM floats between values of 1 and 0 (high and low voltages) before settling on either a 1 or a 0. This is completely random.

Any writable memory in a computer system should ALWAYS be initialised. Never assume anything.

Hi,

Yayyak is mostly right (although AFAIK it does depend on the chipset and RAM chips).

AlfaOmega08 wrote:Until the JMP to 0x7C00, A20 should never have been enabled.

No - for modern 80x86 computers A20 is enabled at reset or power on and then disabled by the BIOS before starting the OS's boot code. It's necessary for the hardware to enable A20 at reset or power on to start the BIOSs code at 0xFFFFFFF0 (or at "0x0FFFF000:0xFFF0" with modified real mode addressing). The BIOS also needs to have A20 enabled to create ACPI tables (normally at the top of RAM), and (usually) to do some simple memory testing.

AlfaOmega08 wrote:Because of this, if I load my kernel at the first MB, I shouldn't initialize each variable to 0, to be sure that they're clean. All the memory is already clean...

How do you know the BIOS started your OS? It's possible for someone else's OS to run (or some other code, like GRUB working as a chainloader), then restore the hardware to a default state, then start your OS's boot code...

However, you shouldn't really need to explicitly initialise each variable to zero seperately. Normally these variables are in the ".bss" section, and all you'd need to do is fill the ".bss" section with zeros (e.g. do a "rep stosd" or a "memset()" instead of doing "myFirstVariable = 0; mySecondVariable = 0; etc").



Cheers,

Brendan

When a computer starts up, the RAM floats between values of 1 and 0 (high and low voltages) before settling on either a 1 or a 0. This is completely random.

Does this mean unused ram might be used as a source of entropy (for non-pseudo-random number generation)?

Unless the computer was unplugged before turned on, the RAM contains random/previous values.

-JL

Yayyak wrote:This is completely random.

Pick a area in memory when your computer starts and use it as the seed in your kernel's random number generator.

Hi,

piranha wrote:Unless the computer was unplugged before turned on, the RAM contains random/previous values.

Once I had a "good" idea: if/when the kernel crashes, write some information into a specific address in RAM and reboot and then get the boot code to check for (and display) this "kernel panic" information, so you can reliably find out what went wrong (without hoping that the kernel and video driver still work).

I implemented it.

I tested it.

It didn't work.

Unfortunately, on most of the computers I tried the BIOS wiped my "kernel panic" information during reset.

You can't rely on unitialized memory being set to any values, including 0x00 and whatever it contained before reset. You also can't assume that memory won't be filled with zeros (or something else), which makes it useless for entropy. Basically you can't make any assumptions of any kind.


Cheers,

Brendan

I own an AMD system that doesn't seem to initialize memory during reboots, and as such.. OpenBSD seems to be able to make use of this "feature" and can retrieve previous boot diagnostic messages as Brendan describes.

This neat little "trick" works on very few of my systems... quite unreliable.

Brendan wrote:Hi,

piranha wrote:Unless the computer was unplugged before turned on, the RAM contains random/previous values.

Once I had a "good" idea: if/when the kernel crashes, write some information into a specific address in RAM and reboot and then get the boot code to check for (and display) this "kernel panic" information, so you can reliably find out what went wrong (without hoping that the kernel and video driver still work).

I implemented it.

I tested it.

It didn't work.

Did you test this on an emulator? Because I think that they do zero all memory...

-JL

actually, there is a way to 'instruct' the BIOS not to alter memory on boot... though i dont remember how to do it...

this technique also tells the BIOS not to load the OS from disk, but instead to simply resume program execution in RMode, at a specific address... as i said, i dont remember the details of how to use it

iirc, windows 9x uses this to run programs which must run in RMode -- rather than in VMode, which it uses for most RMode programs (the 'force real-mode' option in the application properties dialog)

windows/286 also used this to run RMode programs (this 'feature' is a left-over remnant from the 286, when the system had to be reset to switch from PMode to RMode)