ACPI: read memory fe0000-ffffff problem

[jmkerdal]

Hello,

I've a strange effect when I try to read memory from fe0000 to ffffff (type 2 memory).
Look to all screenshots:

It's because I got a panic issue (at the line in blue) that I made some test and I see this:
- dump 4 bytes memory 0xfe1656 directely work (in green = RSDT in ASCII).
- dump from value from the struct fail (in red).

When it's strange is that it's exatly the same value.
Below I show you the bank memory available.

An idea?

[songziming]

The information you provided is not enough. What's the structure of `sdt`, and what's the code of `MEM_dump`? When running this code, are your OS work in single-thread mode?

[mallard]

You're getting a page fault. That almost certainly means that the address you're trying to access isn't mapped. What do your page tables look like? What does the code that creates them do? I'd suggest that your page fault exception handler should at least have the ability to output the contents of the CR2 register that contains the fault address...

What does "MEM_dump" do? I suspect it's not doing what you think it is; it appears to simply output its parameters (it's pretty unlikely that the address 0xFE1656 actually contains the number "4"), but I suspect it's supposed to output a number of bytes of memory from the address given.

If that function isn't working correctly, then nothing attempts to dereference the pointer "sdt->sig" until the "memcmp" call, hence the crash on that line.


Actually, ignore the above italic text (I wonder if this forum will ever update to a version that supports strikethrough formatting; surely a 12-year-old version of phpBB can't be good for server security...). It appears that "MEM_dump" actually outputs the "dumped" memory on the next line and therefore you have two "identical" calls, but only the second causes a crash. That suggests that either; (1) the code to print addresses as hex has a bug and the addresses are not, in fact, identical or (2) "MEM_dump" has a bug meaning it's not actually doing the same thing both times.

The first dump is printing the correct ASCII values for "RSDT", so it appears that the hard-coded address is correct at least.

[jmkerdal]

You right, the code I study has add a wrong page offset.
So the pointer try to read invalid address memory = crash.

Removing this value and all work perfectly.

And yes, MEM_dump is my tool to dump memory in text, like this (HEX translate a char to hex value):

Code: Select all

void MEM_dump(void * src, unsigned long bytes) { // Affiche une zone mémoire en HEXA
    unsigned char * s = (unsigned char *) src;
    char blanc = 0;
    char col = 0;
    printf("MEM_dump: %x %d\n", s, bytes);
    for(register unsigned long i = 0; i < bytes; i++) {
        printf("%s ", HEX(s[i]));
        if (blanc == 3) {
            blanc = 0;            
            if (col == 5) {
                printf("\n");
                col = 0;
            } else {
                printf(" ");
                col++;
            }
        } else blanc++;        
    }
    printf("\n");
}

[mallard]

Is this 32-bit or 64-bit code?

For 64-bit code, the "%x" format specifier will (usually; assuming the common LP64 or LLP64 data models) only print a 32-bit value (and hence, the address passed into the second call to MEM_dump may not be the same as the first). "%p" should be used to print pointer addresses.

I'd still suggest that knowing the address of the page fault (from the CR2 register) would be beneficial in identifying the problem...