XenOS wrote:
Have you had a look at running objdump on your output file? What does your .bss section contain? What is at the address from which you get the fault when NX is enabled? Is that address in the .bss section?
Yeah i did a objdump in disassembly and data mode of my output file and it seems like in .bss is just data. I can't get the address where the fault occurs because i get a tripple-fault as soon as the table is loaded. I debugged it and it seems like my kernel is not able to return from my setCR3-function, which would indicate a problem with the stack:
Code:
1.
2. [global setCR3]
3. setCR3:
4. mov cr3, rdi
5. ret
2. [global setCR3]
3. setCR3:
4. mov cr3, rdi
5. ret
Attachment:
setCR3.PNG [ 32.47 KiB | Viewed 425 times ]
EDIT: Please don't hit me. At least not in my face. I know I'm stupid.
You know what was wrong? I never set the NXE-Bit in the IA32_EFER-MSR... So obviously it didn't work...
Weired thing that it did work with the .data-section, because Bit 63 is reserved and must be 0 if the NXE-Bit is not set...