4

I am trying to learn about the kernel and have been trying, unsuccessfully, for some time to print some of the basic data structures that make up the kernel landscape. My issue is that given a memory address, I'd like to be able to print the contents of that address.

For example, I have a function that determines the location of IDT. It returns (void *) on the order of 0xffff81b8c0000fff. However, whenever I try to printk what's at that address, the result is a kernel panic. I understand that there are protections in place to prevent one from accessing kernel memory from userspace, but I am attempting to do this from within start_kernel, where I would have thought them to be readable.

The code is:

idt_ptr = sidt(); // returns (void *) printk(KERN_INFO "680: IDT TABLE, FIRST ENTRY\n"); //entry is 64 bits printk(KERN_INFO "680: %llx\n", *(unsigned long long *)idt_ptr); 

Here's the tail end of the kernel panic that occurs after making this attempt:

enter image description here

It seems I need a semaphore for read access, but isn't this just an arbitrary address?

1
  • From my experience in OS development, it appears as if you are triggering a page fault. This happens when you try to access paged memory you shouldn't or that doesn't exist. Unfortunately I don't know much more I can say to help you. Commented Apr 16, 2012 at 2:33

2 Answers 2

6

For example, I have a function that determines the location of IDT. It returns (void *) on the order of 0xffff81b8c0000fff

No pointer to anything other than char* could possibly equal 0x...ff -- that address is not properly aligned for a pointer to a data structure containing anything other than chars.

Conclusion: your sidt function is broken and returns bogus address.

Sign up to request clarification or add additional context in comments.

2 Comments

Based on the other addresses, I'd say that the real address is probably 0xffffffff81b8c000 - the 0x0fff is highly likely to be the 16-bit IDT limit. The OP should note that the sidt opcode writes a 10-byte value, where the lower two bytes are the 16-bit limit and the upper 8 bytes are the address.
I was afraid that this might be the case. I had been trying to test it in userland, but because I couldn't access kernel memory anyway, I couldn't tell if my address was bad or I couldn't access its contents. What caf said makes a lot of sense, and I shall try it at the earliest opportunity and report back. Thanks.
1

I recommend giving kdb a go for poking around inside the kernel.

Try setting up a KVM or qemu VM with a kdb-patched kernel.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.