Using IoGetDriverObjectExtension with miniport driverObject and port driver EP as Identification?

I am reviewing some driver code, and in it, it’s using IoGetDriverObjectExtension( miniport_driverObj , portDriver_entrypoint), and the entry point of driver is the real entrypoint and not the GS, so my question is what’s the point of doing this? does this return the driver Extension of miniport or…? and does it have to be the real entrypoint of the port driver ? what will happen if i use the entrypoint of the miniport driver or the gsEntrypoint of port driver?

The second parameter is just an identifier/cookie. A function pointer value is globally unique in kernel address space so it is a simple, easy ID to use. It doesn’t matter if it is the real EP or the thunked one, just that it is unique enough to identify which driver object extension you want to retrieve

@Doron_Holan said:
The second parameter is just an identifier/cookie. A function pointer value is globally unique in kernel address space so it is a simple, easy ID to use. It doesn’t matter if it is the real EP or the thunked one, just that it is unique enough to identify which driver object extension you want to retrieve

Thanks for answer, so is the identifier for getting the driver Extension of the miniport always the real entry point of its port driver?

If the driver extension is only retrieved by the mini port it doesn’t matter which function pointer value you use.

@Doron_Holan said:
If the driver extension is only retrieved by the mini port it doesn’t matter which function pointer value you use.

I know, but I want to know what kernel itself uses for the ID, does it always use the real driver entry of port driver for the ID all the time?

The kernel doesn’t give a whack-doodle about your driver context. It’s never going to fetch it on its own. You allocate space with IoAllocateDriverObjectExtension using whatever ID you want, and you fetch it later with IoGetDriverObjectExtension using that same ID. It is an exchange that is totally private to the driver.

What bigger problem/bug are you trying to solve? The kernel does nothing with nor knows nothing about this address/function pointer value. The code that passes the pointer value is entirely in your driver, as such the resolution of that address is entirely in your driver. The address of DriverEntry != GsDriverEntry (GsDriverEntry is typically not even a known function in your source as it is added through a library w/out a header declaring it).

@Doron_Holan said:
What bigger problem/bug are you trying to solve? The kernel does nothing with nor knows nothing about this address/function pointer value. The code that passes the pointer value is entirely in your driver, as such the resolution of that address is entirely in your driver. The address of DriverEntry != GsDriverEntry (GsDriverEntry is typically not even a known function in your source as it is added through a library w/out a header declaring it).

There is no bigger problem/bug, i just want to understand this : if i get the driver object of the miniport of the disk stack, then get its real entry point (not the one in the driver object), then pass them to IoGetDriverObjectExtension, will it always return a non NULL value?

because i am reading a source code, which assumes it always does, and want to understand if its true or not?

There’s certainly no guarantee. Most miniports are derived from a sample, so if the sample did it, then most miniports will do it, but it’s an implementation detail.