KMDF: determine originating thread of WDFREQUEST

Hi all,

I have a driver which has an IO queue (WDFQUEUE) to receive requests
(WDFREQUEST) from usermode processes, handles them, and then calls
WdfRequestCompleteWithInformation() to complete them.

My customer has some, well, weird (I call it bullshit) semantics of I2C
communication that I have to implement: a transaction is divided into
non-atomic accesses where transactions may interleave and steal bus
access from each other. This stealing actually happens in rare
circumstances which I use to call a “race condition”, and I want to
protect myself from any blames by implementing an “ownership” to detect
such errors and reject bullshit.

What I envision is to remember the thread that *starts* an I2C
transaction, and to release that owner when it *stops* the transaction -
and to reject any request from a different thread should that happen in
the middle of a transaction.

How is this done?

The WDFREQUEST objects that I receive via the WDFQUEUE are the result of
a usermode thread calling DeviceIoControl(). This usermode thread is the
one that should “own” an ongoing I2C transaction, and thus I have to
remember that thread in driver space. I can imagine that the WDFREQUEST
carries that thread’s ID with it - it’s just that I don’t understand how
to access this information.

Can anybody help me please?

Thank you in advance,
Jörg

DI Jörg Faschingbauer
Linux und Open Source - Programmierung, Beratung und Schulung
http://www.faschingbauer.co.at

Actually, the WDFREQUEST does not carry the thread ID, and the thread in the driver is not guaranteed to be the thread from user mode unless you set up the device with additional calls.

Overall your approach is not viable, can’t you have a START TRANSACTION call that driver returns an ID for, then use the ID in your calls, then have an END TRANSACTION to finish things. I.E. do explicitly what you were trying to do with the thread ID?

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@faschingbauer.co.at
Sent: Thursday, January 25, 2018 7:38 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF: determine originating thread of WDFREQUEST

Hi all,

I have a driver which has an IO queue (WDFQUEUE) to receive requests
(WDFREQUEST) from usermode processes, handles them, and then calls
WdfRequestCompleteWithInformation() to complete them.

My customer has some, well, weird (I call it bullshit) semantics of I2C
communication that I have to implement: a transaction is divided into
non-atomic accesses where transactions may interleave and steal bus
access from each other. This stealing actually happens in rare
circumstances which I use to call a “race condition”, and I want to
protect myself from any blames by implementing an “ownership” to detect
such errors and reject bullshit.

What I envision is to remember the thread that starts an I2C
transaction, and to release that owner when it stops the transaction -
and to reject any request from a different thread should that happen in
the middle of a transaction.

How is this done?

The WDFREQUEST objects that I receive via the WDFQUEUE are the result of
a usermode thread calling DeviceIoControl(). This usermode thread is the
one that should “own” an ongoing I2C transaction, and thus I have to
remember that thread in driver space. I can imagine that the WDFREQUEST
carries that thread’s ID with it - it’s just that I don’t understand how
to access this information.

Can anybody help me please?

Thank you in advance,
Jörg

DI Jörg Faschingbauer
Linux und Open Source - Programmierung, Beratung und Schulung
http://www.faschingbauer.co.at


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

One way to make this work is to have your transaction semantics on the wdffileobject level. The app would open a handle per thread (or transaction) instead of one overlapped handle shared across all threads.

Bent from my phone


From: xxxxx@lists.osr.com on behalf of xxxxx@windrvr.com
Sent: Thursday, January 25, 2018 4:51:18 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF: determine originating thread of WDFREQUEST

Actually, the WDFREQUEST does not carry the thread ID, and the thread in the driver is not guaranteed to be the thread from user mode unless you set up the device with additional calls.

Overall your approach is not viable, can’t you have a START TRANSACTION call that driver returns an ID for, then use the ID in your calls, then have an END TRANSACTION to finish things. I.E. do explicitly what you were trying to do with the thread ID?

Don Burn
Windows Driver Consulting
Website: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.windrvr.com&amp;data=02|01|Doron.Holan%40microsoft.com|f4e61e7044a5460bb7f008d563f26695|ee3303d7fb734b0c8589bcd847f1c277|1|0|636524815110984702&amp;sdata=Hy3KaLYcZnezBvMUOfZfMiacErp4JgVYC7xeZG1aJPs%3D&amp;reserved=0

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@faschingbauer.co.at
Sent: Thursday, January 25, 2018 7:38 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF: determine originating thread of WDFREQUEST

Hi all,

I have a driver which has an IO queue (WDFQUEUE) to receive requests
(WDFREQUEST) from usermode processes, handles them, and then calls
WdfRequestCompleteWithInformation() to complete them.

My customer has some, well, weird (I call it bullshit) semantics of I2C
communication that I have to implement: a transaction is divided into
non-atomic accesses where transactions may interleave and steal bus
access from each other. This stealing actually happens in rare
circumstances which I use to call a “race condition”, and I want to
protect myself from any blames by implementing an “ownership” to detect
such errors and reject bullshit.

What I envision is to remember the thread that starts an I2C
transaction, and to release that owner when it stops the transaction -
and to reject any request from a different thread should that happen in
the middle of a transaction.

How is this done?

The WDFREQUEST objects that I receive via the WDFQUEUE are the result of
a usermode thread calling DeviceIoControl(). This usermode thread is the
one that should “own” an ongoing I2C transaction, and thus I have to
remember that thread in driver space. I can imagine that the WDFREQUEST
carries that thread’s ID with it - it’s just that I don’t understand how
to access this information.

Can anybody help me please?

Thank you in advance,
J?rg

DI J?rg Faschingbauer
Linux und Open Source - Programmierung, Beratung und Schulung
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.faschingbauer.co.at&amp;data=02|01|Doron.Holan%40microsoft.com|f4e61e7044a5460bb7f008d563f26695|ee3303d7fb734b0c8589bcd847f1c277|1|0|636524815110984702&amp;sdata=iVygl6zPH3PJEPhQPVpczMYhfBqU3hTXfeLoWCmMZ4A%3D&amp;reserved=0


NTDEV is sponsored by OSR

Visit the list online at: https:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:

To unsubscribe, visit the List Server section of OSR Online at https:


NTDEV is sponsored by OSR

Visit the list online at: https:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:

To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:></https:></https:></https:>

Sure it does. It’s in the IRP.

But, regardless, it is absolutely true that:

So…

This is the best advice. It’s easy to implement, and it’s handy. The WDF_FILE_OBJECT handle is always available. You can even stuff a context on it., in which you can store per-open-instance stuff.

Will that work for you?

Peter
OSR
@OSRDrivers

What I found when reading the docs was …

WdfRequestGetRequestorProcessId(). Although I’d rather like the sending
thread’s ID, that looks like a hint that the WDFREQUEST somehow exposes
originator information.

IRP.Tail.Overlay.Thread. The docs
(https://msdn.microsoft.com/en-us/library/windows/hardware/ff550694(v=vs.85).aspx)
say that “For requests that originate in user-mode, the I/O manager
always sets this field to point to the TCB of the thread that issued the
request.”

Would IRP.Tail.Overlay.Thread work?

Thanks,
Joerg

On 01/25/2018 01:51 PM, xxxxx@windrvr.com wrote:

Actually, the WDFREQUEST does not carry the thread ID, and the thread in the driver is not guaranteed to be the thread from user mode unless you set up the device with additional calls.

Overall your approach is not viable, can’t you have a START TRANSACTION call that driver returns an ID for, then use the ID in your calls, then have an END TRANSACTION to finish things. I.E. do explicitly what you were trying to do with the thread ID?

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@faschingbauer.co.at
Sent: Thursday, January 25, 2018 7:38 AM
To: Windows System Software Devs Interest List
> Subject: [ntdev] KMDF: determine originating thread of WDFREQUEST
>
> Hi all,
>
> I have a driver which has an IO queue (WDFQUEUE) to receive requests
> (WDFREQUEST) from usermode processes, handles them, and then calls
> WdfRequestCompleteWithInformation() to complete them.
>
> My customer has some, well, weird (I call it bullshit) semantics of I2C
> communication that I have to implement: a transaction is divided into
> non-atomic accesses where transactions may interleave and steal bus
> access from each other. This stealing actually happens in rare
> circumstances which I use to call a “race condition”, and I want to
> protect myself from any blames by implementing an “ownership” to detect
> such errors and reject bullshit.
>
> What I envision is to remember the thread that starts an I2C
> transaction, and to release that owner when it stops the transaction -
> and to reject any request from a different thread should that happen in
> the middle of a transaction.
>
> How is this done?
>
> The WDFREQUEST objects that I receive via the WDFQUEUE are the result of
> a usermode thread calling DeviceIoControl(). This usermode thread is the
> one that should “own” an ongoing I2C transaction, and thus I have to
> remember that thread in driver space. I can imagine that the WDFREQUEST
> carries that thread’s ID with it - it’s just that I don’t understand how
> to access this information.
>
> Can anybody help me please?
>
> Thank you in advance,
> Jörg
>


DI Jörg Faschingbauer
Linux und Open Source - Programmierung, Beratung und Schulung

Yes sure, if requester mode is usermode then tail.thread is valid, plus you
don’t have to convince the customer to change their app.

Mark Roddy

On Tue, Feb 6, 2018 at 1:49 AM, xxxxx@faschingbauer.co.at
wrote:

> What I found when reading the docs was …
>
> WdfRequestGetRequestorProcessId(). Although I’d rather like the sending
> thread’s ID, that looks like a hint that the WDFREQUEST somehow exposes
> originator information.
>
> IRP.Tail.Overlay.Thread. The docs (https://msdn.microsoft.com/en
> -us/library/windows/hardware/ff550694(v=vs.85).aspx) say that “For
> requests that originate in user-mode, the I/O manager always sets this
> field to point to the TCB of the thread that issued the request.”
>
> Would IRP.Tail.Overlay.Thread work?
>
> Thanks,
> Joerg
>
>
> On 01/25/2018 01:51 PM, xxxxx@windrvr.com wrote:
>
>> Actually, the WDFREQUEST does not carry the thread ID, and the thread in
>> the driver is not guaranteed to be the thread from user mode unless you set
>> up the device with additional calls.
>>
>> Overall your approach is not viable, can’t you have a START TRANSACTION
>> call that driver returns an ID for, then use the ID in your calls, then
>> have an END TRANSACTION to finish things. I.E. do explicitly what you
>> were trying to do with the thread ID?
>>
>>
>> Don Burn
>> Windows Driver Consulting
>> Website: http://www.windrvr.com
>>
>>
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com [mailto:bounce-645739-122747@l
>> ists.osr.com] On Behalf Of xxxxx@faschingbauer.co.at
>> Sent: Thursday, January 25, 2018 7:38 AM
>> To: Windows System Software Devs Interest List
>> Subject: [ntdev] KMDF: determine originating thread of WDFREQUEST
>>
>> Hi all,
>>
>> I have a driver which has an IO queue (WDFQUEUE) to receive requests
>> (WDFREQUEST) from usermode processes, handles them, and then calls
>> WdfRequestCompleteWithInformation() to complete them.
>>
>> My customer has some, well, weird (I call it bullshit) semantics of I2C
>> communication that I have to implement: a transaction is divided into
>> non-atomic accesses where transactions may interleave and steal bus
>> access from each other. This stealing actually happens in rare
>> circumstances which I use to call a “race condition”, and I want to
>> protect myself from any blames by implementing an “ownership” to detect
>> such errors and reject bullshit.
>>
>> What I envision is to remember the thread that starts an I2C
>> transaction, and to release that owner when it stops the transaction -
>> and to reject any request from a different thread should that happen in
>> the middle of a transaction.
>>
>> How is this done?
>>
>> The WDFREQUEST objects that I receive via the WDFQUEUE are the result of
>> a usermode thread calling DeviceIoControl(). This usermode thread is the
>> one that should “own” an ongoing I2C transaction, and thus I have to
>> remember that thread in driver space. I can imagine that the WDFREQUEST
>> carries that thread’s ID with it - it’s just that I don’t understand how
>> to access this information.
>>
>> Can anybody help me please?
>>
>> Thank you in advance,
>> Jörg
>>
>>
>
> –
> DI Jörg Faschingbauer
> Linux und Open Source - Programmierung, Beratung und Schulung
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> lists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

Hence my comment two weeks ago:

Peter
OSR
@OSRDrivers