OSDev.org

Hi.
I came across such a funny mistake.
When I wanted to clear the framebuffer, qemu crashed and wrote me this: I spent half an hour wondering why manipulating framebuffer leads to such a problem, especially given that the framebuffer address was equal to 0xFD000000.
It turns out that part of my core tried to write its data(font for ssfn) to this address because it thought it was an accessible part of memory(after all, GRUB told it so).
It turns out that in the memory area that GRUB marked as available there was an address on the network adapter (e1000) and the font loaded there damaged the memory(I still don't understand why qemu fell when trying to write something to framebuffer).

Now I'm not sure about the security of the memory area that GRUB marked as available.
How can I avoid such problems in the future?

Almost certainly you are misinterpreting the memory map. (Although, without a link to your code repository, it is difficult to be certain.)

Are you sure you are checking the "type" field for each map entry?

iansjack wrote:Almost certainly you are misinterpreting the memory map. (Although, without a link to your code repository, it is difficult to be certain.)

Are you sure you are checking the "type" field for each map entry?

Yes, I only use MULTIBOOT_MEMORY_AVAILABLE sections.

As a solution, I decided not to use memory below 1 MB for my purposes, despite the fact that GRUB says that memory from 0x0 to X is available.

In that case, use the information, from the multiboot information, about the location and size of the framebuffer to exclude it from your list of usable memory.

mrjbom wrote:...despite the fact that GRUB says that memory from 0x0 to X is available.

I have that in my bootloader, too. The memory map from the BIOS call:

1.) Base=0 Length=0x9F800 Type=1 (See, same as on your computer!)
2.) Base=0x9F800 Length=0x800 Type=2
3.) Base=0xE6000 Length=0x1A000 Type=2
4.) Base=0x100000 Length=0xCFEA0000 Type=1
5.) Base=0xCFFA0000 Length=0x10000 Type=3
6.) Base=0xCFFB0000 Length=0x30000 Type=4
7.) Base=0xCFFE0000 Length=0x10000 Type=2
8.) Base=0xCFFF0000 Length=0x10000 Type=2
9.) Base=0xFFF00000 Length=0x100000 Type=2
10.) Base=0x100000000 Length=0x20000000 Type=1

Type 1 means freely available memory.
The types are explained here:
http://www.ctyme.com/intr/rb-1741.htm

So, you have to add "reservations" for well-known reserved memory to your memory map. Memory starting a 0x00:0x00 is definitively not free!
There are other reserved memory locations which may be not in the memory map.

EDIT: See also:
https://groups.google.com/forum/#!topic ... qslFI6HNbc

Greetings
Peter

mrjbom wrote:It turns out that part of my core tried to write its data(font for ssfn) to this address because it thought it was an accessible part of memory(after all, GRUB told it so).

GRUB did not tell you that the network adapter's MMIO is available memory. You're either parsing the memory map wrong, or you have some other bug that causes bad memory accesses.

I'm inclined to believe you're parsing the memory map wrong, since the addresses and lengths in the memory map are 64 bits, but you don't seem to be using uint64_t to parse the map.

PeterX wrote:Memory starting a 0x00:0x00 is definitively not free!

It's supposed to be! You don't need anything in that region of RAM after your OS boots, and it's safe to overwrite. Unfortunately, some buggy firmware will write to the first 64kB of RAM while your OS is running, so you can't store anything there.

Octocontrabass wrote:

mrjbom wrote:It turns out that part of my core tried to write its data(font for ssfn) to this address because it thought it was an accessible part of memory(after all, GRUB told it so).

GRUB did not tell you that the network adapter's MMIO is available memory. You're either parsing the memory map wrong, or you have some other bug that causes bad memory accesses.

I'm inclined to believe you're parsing the memory map wrong, since the addresses and lengths in the memory map are 64 bits, but you don't seem to be using uint64_t to parse the map.

PeterX wrote:Memory starting a 0x00:0x00 is definitively not free!

It's supposed to be! You don't need anything in that region of RAM after your OS boots, and it's safe to overwrite. Unfortunately, some buggy firmware will write to the first 64kB of RAM while your OS is running, so you can't store anything there.

Apparently, this is some kind of problem with memory_map, GRUB marks the first 636 KB(0x0 - 0x9f000) as available.

I will not use memory below 1 MB, I hope I will not have any more such surprises.

mrjbom wrote:Apparently, this is some kind of problem with memory_map, GRUB marks the first 636 KB(0x0 - 0x9f000) as available.

GRUB is correct, it is available. (Aside from firmware bugs with the first 64kiB.)

The e1000 error messages in QEMU are referring to offsets relative to the e1000 MMIO base. The e1000 MMIO base is somewhere in the 0xC0000000-0xFFFFFFFF range.

You still have a bug somewhere, and it will cause trouble later if you don't figure out where it is now.

Octocontrabass wrote:

mrjbom wrote:Apparently, this is some kind of problem with memory_map, GRUB marks the first 636 KB(0x0 - 0x9f000) as available.

GRUB is correct, it is available. (Aside from firmware bugs with the first 64kiB.)

The e1000 error messages in QEMU are referring to offsets relative to the e1000 MMIO base. The e1000 MMIO base is somewhere in the 0xC0000000-0xFFFFFFFF range.

You still have a bug somewhere, and it will cause trouble later if you don't figure out where it is now.

That's all right. I work with a range from 0x100000 to 0xbffe0000.