I just re-subscribed after years, maybe somebody remembers me I didn’t
write Windows drivers since 2012 but now I was asked to solve a problem
which probably needs one. I found my memory leaked and I’m unsure about many
things which were obvious before. Reading docs and searching doesn’t clear
everything so I decided to ask here to find definitive answers. My goal is
to choose proper solution before development starts and avoid trial/error
scenario. I’m sorry if some of my questions are RTFM or just dumb and also
about long post. I’m trying to explain whole problem in the case I’m gluing
wings to a pig and there is a better solution. Questions on the end.
The problem: a smardcard reader with a keypad and PIN support. Windows USB
CCID class driver (WUDFUsbccidDriver.dll, UMDF) doesn’t support keypad but
otherwise works as necessary. The PIN support is already standardized and
applications using it are written and work (at least) on Linux. Basically,
application issues new IOCTL_GET_FEATURE_REQUEST to get a list of features
which device supports and IOCTL codes to be used to handle them. In this
case IOCTL_VERIFY_PIN_DIRECT and IOCTL_MODIFY_PIN_DIRECT. The natural
solution seems to be using Windows class driver and extend its functionality
using a filter driver.
IOCTL_GET_FEATURE_REQUEST can be implemented using upper filter but there is
a problem with the real functionality. PIN IOCTLs need to send USB CCID
requests which Windows class driver doesn’t support (PC_to_RDR_Secure) and
it doesn’t offer to pass through functionality. It could be sent using a
lower filter, directly using PDO access or tunnel through using a supported
request.
The target OS is Win10+ which can hopefully simplify things a little bit.
Class driver is UMDF 1.11 driver there.
Possible solutions:
Upper filter + firmware modification. Filter would tunnel PIN requests
using class driver interface IOCTL_SMARTCARD_TRANSMIT or IOCTL_CCID_ESCAPE
which would be translated to PC_to_RDR_XfrBlock or PC_to_RDR_Escape CCID
requests. Firmware would be able to detect tunneled requests and forward
them to proper PC_to_RDR_Secure handler and return responses similar way.
Preferred solution for now.
Upper filter + lower filter. As #1 but lower filter would modify tunneled
requests to PC_to_RDR_Secure and vice versa with responses. Alternatively,
upper and lower filters could make a side channel and send PIN requests
through it. It is ugly, because class driver wouldn’t see these requests and
its internal state wouldn’t fully match device state (there are sequence
numbers for example). Also, I’m not sure how it could influence power
management.
Upper filter + direct PDO access. Upper filter would send PIN requests
directly to PDO. It is fugly, the same drawback as #2 side channel plus
upper filter wouldn’t know pipe handles and had to build URBs manually (if
even possible).
For completeness, refused solutions:
4. Applications change + firmware modification. As #1 but applications would
send and handle PIN (tunnel) requests directly. I strongly recommended it
but it was refused because “not all applications can be changed” (which I
doubt). I tried to explain that having a Windows driver for a company which
never had any is major PITA and anything else is better but apparently
failed.
Write full driver replacing class driver. Most of code would duplicate
class driver functionality.
Handle PIN using a side channel as HID endpoint. Ugly, non-standard, “not
all applications…” etc.
Questions:
Can be #1 implemented using UMDF (UMDF upper filter over UMDF driver) (I
presume yes).
Can be #1 implemented using KMDF? (KMDF upper filter over UMDF driver).
Class driver INF contains UmdfKernelModeClientPolicy=AllowKernelModeClients
if it matters.
Can be #2 implemented using UMDF? Both lower and upper filters for UMDF
driver. Does it need two binaries or is one possible?
What about UMDF versions? Class driver is UMDF 1 (1.11), have to be
filters also UMDF 1 or is UMDF 2 possible? I’ve read somewhere all UMDF
drivers in the stack have to be continuous block and the same version.
Can be #3 (direct PDO access) implemented using UMDF? If so, how? Remote
target? Build URBs in user mode?
Can be direct PDO access implemented using KMDF upper filter? How?
Can UMDF upper filter access device USB descriptors somewhat? There is
some info about smartcard reader features encoded in them.
I understand spelling discussion is much more interesting than UMDF filters
but I still hope somebody here could answer at least some of my questions.
Well, my post was probably too long so I’ll extract just questions and
rephrase them more general way:
Is it possible to have UMDF upper filter over UMDF function (class)
driver? (I presume yes).
Is it possible to have KMDF upper filter over UMDF function (class)
driver? Class driver INF contains
UmdfKernelModeClientPolicy=AllowKernelModeClients if it matters.
Is it possible to have both UMDF upper and lower filter for UMDF function
(class) driver? If so, can it be made using single binary or are two
necessary?
What about UMDF versions? Class driver is UMDF 1 (1.11), have to be
filters also UMDF 1 or is UMDF 2 possible? I’ve read somewhere all UMDF
drivers in the stack have to be continuous block and the same version.
Can UMDF upper filter access PDO directly? If so, how? Remote target?
Build URBs in user mode?
Can be direct PDO access implemented using KMDF upper filter? How?
Can UMDF upper filter access device USB descriptors somewhat?
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-659851- xxxxx@lists.osr.com] On Behalf Of xxxxx@centrum.cz
Sent: Tuesday, August 21, 2018 3:57 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] UMDF filter driver questions
Hi everybody,
I just re-subscribed after years, maybe somebody remembers me I didn’t
write Windows drivers since 2012 but now I was asked to solve a problem
which probably needs one. I found my memory leaked and I’m unsure about
many
things which were obvious before. Reading docs and searching doesn’t clear
everything so I decided to ask here to find definitive answers. My goal is
to choose proper solution before development starts and avoid trial/error
scenario. I’m sorry if some of my questions are RTFM or just dumb and also
about long post. I’m trying to explain whole problem in the case I’m
gluing
wings to a pig and there is a better solution. Questions on the end.
The problem: a smardcard reader with a keypad and PIN support. Windows
USB
CCID class driver (WUDFUsbccidDriver.dll, UMDF) doesn’t support keypad
but
otherwise works as necessary. The PIN support is already standardized and
applications using it are written and work (at least) on Linux. Basically,
application issues new IOCTL_GET_FEATURE_REQUEST to get a list of
features
which device supports and IOCTL codes to be used to handle them. In this
case IOCTL_VERIFY_PIN_DIRECT and IOCTL_MODIFY_PIN_DIRECT. The
natural
solution seems to be using Windows class driver and extend its
functionality
using a filter driver.
IOCTL_GET_FEATURE_REQUEST can be implemented using upper filter but
there is
a problem with the real functionality. PIN IOCTLs need to send USB CCID
requests which Windows class driver doesn’t support (PC_to_RDR_Secure)
and
it doesn’t offer to pass through functionality. It could be sent using a
lower filter, directly using PDO access or tunnel through using a
supported
request.
The target OS is Win10+ which can hopefully simplify things a little bit.
Class driver is UMDF 1.11 driver there.
Possible solutions:
Upper filter + firmware modification. Filter would tunnel PIN requests
using class driver interface IOCTL_SMARTCARD_TRANSMIT or
IOCTL_CCID_ESCAPE
which would be translated to PC_to_RDR_XfrBlock or PC_to_RDR_Escape
CCID
requests. Firmware would be able to detect tunneled requests and forward
them to proper PC_to_RDR_Secure handler and return responses similar
way.
Preferred solution for now.
Upper filter + lower filter. As #1 but lower filter would modify
tunneled
requests to PC_to_RDR_Secure and vice versa with responses. Alternatively,
upper and lower filters could make a side channel and send PIN requests
through it. It is ugly, because class driver wouldn’t see these requests
and
its internal state wouldn’t fully match device state (there are sequence
numbers for example). Also, I’m not sure how it could influence power
management.
Upper filter + direct PDO access. Upper filter would send PIN requests
directly to PDO. It is fugly, the same drawback as #2 side channel plus
upper filter wouldn’t know pipe handles and had to build URBs manually (if
even possible).
For completeness, refused solutions:
4. Applications change + firmware modification. As #1 but applications
would
send and handle PIN (tunnel) requests directly. I strongly recommended it
but it was refused because “not all applications can be changed” (which I
doubt). I tried to explain that having a Windows driver for a company
which
never had any is major PITA and anything else is better but apparently
failed.
Write full driver replacing class driver. Most of code would duplicate
class driver functionality.
Handle PIN using a side channel as HID endpoint. Ugly, non-standard,
“not
all applications…” etc.
Questions:
Can be #1 implemented using UMDF (UMDF upper filter over UMDF
driver) (I
presume yes).
Can be #1 implemented using KMDF? (KMDF upper filter over UMDF
driver).
Class driver INF contains
UmdfKernelModeClientPolicy=AllowKernelModeClients
if it matters.
Can be #2 implemented using UMDF? Both lower and upper filters for
UMDF
driver. Does it need two binaries or is one possible?
What about UMDF versions? Class driver is UMDF 1 (1.11), have to be
filters also UMDF 1 or is UMDF 2 possible? I’ve read somewhere all UMDF
drivers in the stack have to be continuous block and the same version.
Can be #3 (direct PDO access) implemented using UMDF? If so, how?
Remote
target? Build URBs in user mode?
Can be direct PDO access implemented using KMDF upper filter? How?
Can UMDF upper filter access device USB descriptors somewhat? There is
some info about smartcard reader features encoded in them.
Can be extension INF
(https://docs.microsoft.com/en-us/windows-
hardware/drivers/install/using-an-
extension-inf-file) used for installation of upper and lower filters in
this
case?
Thanks,
Michal Vodicka
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:>
You guy’s are really disappointing. I opened the thread to get help on an issue but you are out of the issue. If you have no knowledge on the issue i posted please stop posting. Don’t waste my time as well as your’s.
Am I the only one who finds these two…ugh, “not-so-different from one another”, so to say?
From: xxxxx@lists.osr.com [mailto:bounce-660136- xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, August 23, 2018 9:56 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] UMDF filter driver questions
Am I the only one who finds these two…ugh, “not-so-different from one
another”, so to say?
actually, I see real differences but whatever…
Anton, the very first post I saw when re-subscribed after years was yours. I
saw “soviet_bloke” and “masterpieces” and said to myself: nothing changed
From: xxxxx@lists.osr.com [mailto:bounce-660137- xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Thursday, August 23, 2018 10:02 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] UMDF filter driver questions
I’d be happy to help you, but I’ve never used UMDF in a serious project.
Thanks, I understand and I even wrote an UMDF driver in the past but not a
filter.
I don’t see why this WOULDN’T work. But that’s a long way from knowing
for
a fact that it does work.
Exactly. My problem is I think some things should work but I’m not sure and
reading docs doesn’t help too much. And I want to be sure before development
starts. It would be embarrassing to select a solution, start development and
later find this isn’t a way to go.
It’s August. Everyone’s on holiday.
I see If I get no usable answers, I’ll reopen it at September after I
return from holiday
:> -D actually, I see real differences but whatever…
Fair enough…
The only thing the former quotations complains about is OT discussion on the thread started by the OP. However, in the latter case the OP indirectly complains about OT discussion on the thread that has no relationship to him whatsoever.
In other words, the sense of entitlement seems to be, indeed, much more pronounced in the latter case. Therefore, if you feel that your “talent” is somehow belittled by such a comparison, I am really sorry…
I saw “soviet_bloke” and “masterpieces” and said to myself: nothing changed
Did you notice that I am still posting via the web interface? IIRC, for this or that reason, it used to be a HUGE issue for you for 10 years ago…
complains about OT discussion on the thread that has no relationship to
him
whatsoever.
So you had to fix it and start OT in my thread? Thank you.
Just curious: do you really think complaint was the reason I wrote it?
Therefore, if you feel that your “talent” is
somehow belittled by such a comparison, I am really sorry…
nope.
Did you notice that I am still posting via the web interface? IIRC, for
this or
that reason, it used to be a HUGE issue for you for 10 years ago…
Sorry, I really don’t remember it. My memory leaks and I had so many other
discussions (elsewhere) since then… What was the issue? Quote tags? It is
the only thing which looks strange to me in some of your posts now. I mean,
formatting related
For the nine thousandth time… Anton: Sit down and shut the fuck up.
Your posts fall into three categories:
Useful
Amusing
Annoying, combative, rude, and senseless
The number of posts in the first category has become infinitesimally small, and the ratio of Amusing to Annoying seems to be ever decreasing.
Mr. Vodicka, a long established and respected Windows driver developer, returns to our midst after years of wandering in the wilderness and you do what… badger him? Just. Cut. The. Shit.
Really, truly, I’m tiring of your game and I’m getting perilously close to banning you for the greater good.
No, it is just a reader with a small keypad. It is made by a company which
asked me to find how to make it working at Windows. They’re mostly Linux
guys and there it works because drivers there already support PCSC 2.02.09
specification
(pcscworkgroup.com/Download/Specifications/pcsc10_v2.02.09.pdf). It is dated
November 2012 so I understand it is too new and Win10 class driver can’t
support it
To be honest, I’m not very familiar with smartcards (yet?) but I guess I
don’t have to be. All they need is to find a way how to transfer PIN
requests between applications and hardware using existing class driver. It
is mandatory because their device has to work for Windows login, too. They
already have it working using WinUsb and libusb but it is usable just for
development, not for end users.
Michal
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-660218- xxxxx@lists.osr.com] On Behalf Of xxxxx@fastmail.fm
Sent: Friday, August 24, 2018 3:49 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] UMDF filter driver questions
> The problem: a smardcard reader with a keypad and PIN support.
Hi Michal. Welcome back.
So is your keyboard similar to this?
If yes, are you looking how to put it in “secure mode”, when it directly
reads
the keys for the pin invisible to the host PC?
Regards,
– pa
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:>
I don’t think so, it is their own custom hardware and firmware but I can ask
them. Thanks for the tip.
Michal
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-660240- xxxxx@lists.osr.com] On Behalf Of xxxxx@fastmail.fm
Sent: Friday, August 24, 2018 5:29 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] UMDF filter driver questions
> No, it is just a reader with a small keypad.
This thing is probably same as keyboards (Dell, HP…) based on the
Gemalto
chip
(but they also have the 2nd keyboard function) so their Windows driver can
be useful for you. At least, same idea.
– pa
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:>
Is it possible to have UMDF upper filter over UMDF function (class)
driver? (I presume yes).
Is it possible to have KMDF upper filter over UMDF function (class)
driver? Class driver INF contains
UmdfKernelModeClientPolicy=AllowKernelModeClients if it matters.
Is it possible to have both UMDF upper and lower filter for UMDF function
(class) driver? If so, can it be made using single binary or are two
necessary?
The documentation has three limitations that are relevant here.
First, it says that you cannot have a UMDF class filter.Ă‚ It can only be
a device filter.Ă‚ Second, it states that you can only have one
contiguous block of UMDF drivers per stack. Third, it says you cannot
mix UMDF 1 and 2.
So, you can have WDM -> KMDF -> UMDF -> UMDF -> UMDF -> KMDF -> WDM
etc., but you cannot have KMDF -> UMDF -> KMDF -> UMDF -> KMDF.
What about UMDF versions? Class driver is UMDF 1 (1.11), have to be
filters also UMDF 1 or is UMDF 2 possible? I’ve read somewhere all UMDF
drivers in the stack have to be continuous block and the same version.
Right, you cannot mix them.
Can be direct PDO access implemented using KMDF upper filter? How?
Yes. there are several ways to get your PDO.Ă‚ If nothing else,
WdfIoTargetWdmGetTargetPhysicalDevice can get the PDEVICE_OBJECT, and
you can open an I/O target from that.
Note that I have cleverly omitted the question I couldn’t answer.
Well, I missed this one, thank you for pointing it out. How am I expected to find answers about UMDF architecture in an article named “Installing a UMDF Filter Driver”? It seems I was in the wilderness too long and lost an ability to find relevant MS docs
First, it says that you cannot have a UMDF class filter. It can only be
a device filter.
Just to be sure: I guess I can install inbox UMDF class driver for a single device (VID/PID) and an UMDF filter over and/or under it. Right?
So, you can have WDM -> KMDF -> UMDF -> UMDF -> UMDF -> KMDF ->
WDM
etc., but you cannot have KMDF -> UMDF -> KMDF -> UMDF -> KMDF.
That’s really interesting limitation. OK for me but I’d be curious about reason.
Note that I have cleverly omitted the question I couldn’t answer.
Just to be sure: I guess I can install inbox UMDF class driver for a single device (VID/PID) and an UMDF filter over and/or under it. Right?
Yep, that should work.
> So, you can have WDM -> KMDF -> UMDF -> UMDF -> UMDF -> KMDF ->
> WDM etc., but you cannot have KMDF -> UMDF -> KMDF -> UMDF -> KMDF.
That’s really interesting limitation. OK for me but I’d be curious about reason.
I don’t know whether they actually enforce this, or if it is just a
strong suggestion.Ă‚ You can certainly imagine the practical reasons why
this is a a bad idea.Ă‚ Every K/U and U/K transition means marshalling
the IRP and its data up to or back from user mode, and blocking the
kernel IRP processing while it waits for a process context switch into
the UMDF management service.Ă‚ If you do that more than once or twice,
performance goes to hell.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
the IRP and its data up to or back from user mode, and blocking the
kernel IRP processing while it waits for a process context switch into
the UMDF management service. If you do that more than once or twice,
performance goes to hell.
Do you think requests within one UMDF drivers block (upper UMDF filter -> UMDF driver -> lower UMDF filter) are going directly from driver to driver and not through kernel redirector?
For the nine thousandth time… Anton: Sit down and shut the fuck up.
Poor Anton. For me it just a fun now but if he is doing this all the time…
I guess he deserves it
Mr. Vodicka, a long established and respected Windows driver developer,
returns to our midst after years of wandering in the wilderness
That’s the most funny part. You know, what is my hobby? Mountains,
wilderness, so I really do what you said. I’m even co-moderating a
discussion group related to outdoor activities and discuss there too much.
We even have a guy similar to Anton there, maybe every list/forum has its
Anton
I didn’t
actually, I see real differences but whatever…