Subject: Re: SoC: NDIS
To: Andrew R. Reiter <>
From: Alan Ritter <>
List: tech-kern
Date: 08/01/2005 11:35:58

> Watch out in the PE loader code for making the assumption that there will
> always be the maximum number of Data Directories in the optional header.
> In Bill Paul's code, he blindly bcopy's... however, with his routine that
> retrieves data directories, he does check to see if the index being looked
> for is "out of bounds," so this is OK.  But in pe_get_section_header(), he
> blindly points to the start of the section eaders without checking the
> size of the optional header.  I suggest fixing that so you don't overshoot
> and miss any sections.  Basically, not all DD's are required and many
> don't even apply in kernel-land.

I think I may have finally ran into a problem with this.  So far I haven't
had to make any modifications to the PE code (subr_pe.c), and I've been
able to call into the binary Windows driver and it's been calling
NdisXXX() functions just fine.  Right now I'm trying to get through the
MiniportInitalize() function (inside the Windows binary).  It calls a
bunch of the Ndis functions to set up the device, then it blows up after
the following machine instruction:

jmp ds:0xc0a5d548

This is what happens when I try to step past it:

8: x/i $pc 0xc0a5d410 : jmp ds:0xc0a5d548
(gdb) si
0x00057fd4 in ?? ()
8: x/i $pc 0x57fd4: Cannot access memory at address 0x57fd4
Disabling display 8 to avoid infinite recursion.

As you can see the program counter is getting set to an invalid memory
address.  I'm thinking this might be a problem with how the segment
registers are set up.

Anyway I don't know much at all about the segment registers on x86
processors or executable file formats.  I'm wondering if you think this
has to do with the problem you were mentioning in June, and if so do you
have any pointers to more documentation on the subject?


P.S. check out my blog on this project for more info:
and here's a link to my current sources on the web: