The driver signing issue which was raised is something that emerged after
I stopped working on drivers. What it basically says is that there is no
advantage to using resources over embedding the code in the driver.
However, a UMDF driver would need to retain an open instance handle to the
executable to use FindResource/LoadResource sequences. But AFAIK, drivers
do not get instance handles, so there is no built-in way to simply request
the resources in the same way you ask for app resources. What you would
have to do is LoadLibrary on the .sys file that constitutes your driver,
using the flag that causes it to only load the resources without trying to
load code or resolve pending imports required. The module is not callable
because it has unresolved external links, but the instance handle you get
can be used to access the resources. I do not know enough about the UMDF
operating environment to know if GetModuleName(NULL, …) will actually
return the name of the .sys file, but that is certainly what I would try
first to see if it produces a valid value. Once you have that, your UMDF
driver might well be able to use the familiar app-level
LoadLibrary/Freelibrary to get or free an instance handle that can be used
to access the executable image’s resources. However, you may be skirting
on the thin edge between “unsupported” and “disaster”. And there would be
no good KMDF equivalents; you would probably be deep into Undocumented
Territory with all that implies if you went after resources from within a
kernel driver.
So, because of the new requirements for signing, particularly on x64,
there does not seem to be any advantage to putting the bits in the
resource segment, since new firmware bits are going to require a new
signed driver anyway. It was not clear to me from the message if the .bin
file is managed in the signature-authentication computation during driver
load; if so, then there is no advantage of using it, because, while the
signing eliminates the attack surface, it only adds gratuitous complexity
to the installer without any significant payback.
The comment about “exponentially slower” does not seem to fit; unless the
page faults go up as a power of the size of the firmware, you can’t have
exponential growth. You can have a massive /linear/ growth; note that
O(n) really means t.setup + C * n + t.teardown, and if C is large (the
“constant of proportionality”) then n can hurt badly. But if your
firmware occupies n pages, and you suffer one page fault for each, you may
never notice any slowdown at boot time/dehibernate time/wakeup time
because the C in the I2C is fairly large, and could easily dominate the C
required to page a new page in every 4096 bytes (and if this is causing
massive slowdowns at boot/etc. time, the problems may be deeper than you
can address, and nothing you can do will make any difference anyway.) I
won’t believe “exponentially slower” unless I am given some data to show
that, for example, the slowdown is O(x^n), for x some constant > 1, and n
is the number of page faults to be processed.
Note that if the .bin file does not have its contents checked against the
digital signature, using the separate file definitely increases the attack
surface to the point where it becomes arguable if security actually exists
at all; if it is included in the signature checking, then it has no
advantage over embedding it in the .sys file as a massively large
pre-initialized data segment declaration in the source code (how large
this is depends on how you expand it; for example, if you expand four
bytes of binary into
…, 0xFF, 0xFE, 0x00, 0x02, …
that is, six source characters per byte, you will have a minimum of 6:1
expansion, but there are more efficient ways to write this
0xfeff, 0x0200.
in a pre-initialized WORD array, which, if I’ve counted correctly,
requires a 4:1 expansion, or as
…, 0x0200feff, …
in a pre-initialized DWORD array, which (IICC) requires a 3:1 expansion.
Some idea of the scale of your firmware might help suggest tradeoffs. Is
it 4KB, 4MB or 4GB, for example?
joe
joe
All,
I previous posted an issue about not getting resources assigned to a UMDF
2.0 driver. Converting to KMDF fixed this problem. But it created a new
one.
The driver I am writing needs to download firmware to a device. This is
on Windows 8.1 (obviously, since I am trying to use UMDF 2.0). I was
originally hoping to write a UMDF 2.0 driver and use
FindResource/LoadResource/LockResource/SizeofResource to load and obtain
the size of the firmware, and then download it over I2C.
I searched online for this, and ran into this link:
http://www.osronline.com/ShowThread.cfm?link=239932.
The question have is, from the thread discussion, there was strong
pushback for embedding firmware into the driver. Arguments for embedded
are: reduction of attack surface, and preference to update the driver with
new firmware each time the firmware needs to be updated. This is
obviously quite easy with UMDF 2.0, but there is that resources issue I am
running into.
Whether I can go the UMDF 2.0 route or not later (I am told I should be
able to, but I have yet to learn of the technical reason why the usermode
version of the driver isn’t receiving resources), I think I should go the
ZwOpenFile/ZwReadFile/ZwCloseFile route for now, just to get going.
But long term, if I cannot go to UMDF 2.0 for whatever reason, should I
keep using the ZwXxx API or is there another solution that has come around
since the posting of that other thread?
Thanks in advance,
ck
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer