[SOLVED]Grub2 memory map entries ba...

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
0xd3ba
Posts: 8
Joined: Mon Apr 29, 2019 1:52 am

[SOLVED]Grub2 memory map entries ba...

Post by 0xd3ba »

Hello again,
I would like help with the following issue.
I'm following Multiboot2 specification (https://www.gnu.org/software/grub/manua ... iboot.html)
What I'm doing is checking the addresses of the memory map entries inside GDB's register dump:

Code: Select all


uint64_t main(uint32_t magic, uint32_t mbi) {

. . . . 

if(tag->type == MBOOT_TAG_MMAP){
            struct mboot_mmap *mmap = (struct mboot_mmap *)tag;
            struct mboot_mmap_entry *entry = mmap->entries;
            
            i=0;
            while((uint32_t)entry < (uint32_t)mmap + mmap->size){
                i++;
                if(i==2) return entry->base_addr;
                entry = (struct mboot_mmap_entry *)((uint32_t)entry + mmap->entry_size);
            }
. . . . 
(Basically i is the entry number I'm interested in, returning i'th entry's base_address (ending up in EAX) and halting the CPU) - inefficient but have no other choice (no printk..etc)
The issue is that all the entry's base addresses are being returned as 0. (Tried for all possible values of i)
I'm supplying 32MB of RAM from qemu and basic memory information (mem_lower and mem_upper values are being returned correctly - around 639KB for mem_lower and around 31.5 MB for mem_upper)

And entry->type is also returning 0 !! (even for 1st entry). This is driving me crazy

Structures for mmap and mmap_entry are as follows:

Code: Select all

struct mboot_mmap_entry {
    mboot64_t   base_addr;
    mboot64_t   length;

    #define MBOOT_MEMORY_AVAILABLE    1
    #define MBOOT_MEMORY_RESERVED    2
    #define MBOOT_MEMORY_ACPI_RECLAIMABLE    3
    #define MBOOT_MEMORY_NVS    4
    #define MBOOT_MEMORY_BADRAM    5

    mboot32_t   type;
    mboot32_t   zero;
};

struct mboot_mmap {
    mboot32_t   type;
    mboot32_t   size;
    mboot32_t   entry_size;
    mboot32_t   entry_type;
    mboot32_t   entry_version;
    struct mboot_mmap_entry entries[0];
};
Any idea about this issue ?

Thanks
Last edited by 0xd3ba on Mon Aug 26, 2019 12:34 pm, edited 1 time in total.
Octocontrabass
Member
Member
Posts: 5223
Joined: Mon Mar 25, 2013 7:01 pm

Re: Grub2 memory map entries returning base addresses as 0

Post by Octocontrabass »

0xd3ba wrote:(Basically i is the entry number I'm interested in, returning i'th entry's base_address (ending up in EAX) and halting the CPU) - inefficient but have no other choice (no printk..etc)
Not just EAX. You're returning a 64-bit integer, which means the upper half is in EDX. What values are you seeing in EDX? Does it look suspiciously similar to each entry's length instead of the base_address? As if your code is reading four bytes past where it should be?
0xd3ba wrote:Structures for mmap and mmap_entry are as follows:
One of these structures doesn't match the specification. The difference is an extra four bytes...
0xd3ba
Posts: 8
Joined: Mon Apr 29, 2019 1:52 am

Re: Grub2 memory map entries returning base addresses as 0

Post by 0xd3ba »

One of these structures doesn't match the specification. The difference is an extra four bytes...
So THIS was the thing that was causing the issue *facepalm*
Not just EAX. You're returning a 64-bit integer, which means the upper half is in EDX. What values are you seeing in EDX? Does it look suspiciously similar to each entry's length instead of the base_address? As if your code is reading four bytes past where it should be?
I can't believe I overlooked the part that EAX is only 32bits :oops:

Anyways, everything is now working as it should be !
THANKS A LOT !! :mrgreen: :mrgreen:
Post Reply