If Mr. Lockard said it, in this context, you can take it to the bank.
Yes, I admit my knowledge was out of date. I have to say it surprises me greatly that there are now classes of devices that can no longer be used on Windows. More impetus to move to Linux, I guess.
INF directives/sections that will block signing are now tagged as such in the docs, such as https://learn.microsoft.com/en-us/windows-hardware/drivers/install/inf-logconfig-directive
Yes, I admit my knowledge was out of date. I have to say it surprises me greatly that there are now classes of devices that can no longer be used on Windows. More impetus to move to Linux, I guess.
I’m entirely in your camp on this one, Mr. Roberts.
In fact, it does more than surprise me greatly. I find it foolish, short-sighted, and perhaps even slightly professionally offensive. Apparently our colleagues in Redmond don’t know, or don’t care, that there are still lots and lots of industrial automation and factory floor devices that are ISA-based. I guess the attitude is: Redesign it as a PCIe device, or forget about it.
However, I DO admit to now being used to this type and level of offense when it comes to driver signing. I got used to it when MSFT made it impossible to sign a Windows 7, Windows 8, or Windows 8.1 driver that did not pass the logo tests. Try as I might, and I tried mightily, I could not get a single, solitary, person that I spoke with at MSFT to understand (or perhaps care) that there are legitimate categories of devices that will never be logo-able under any circumstances.
It has become very clear that MSFT does not care, even a little bit, about process control or embedded systems.
Never mind… I am merely railing against the tide.
Love having you here, Mr. Lockard. No offense. But what you’ve explained to us is outright bad policy.
To be clear (in case it wasn’t), all of these directives still work and will continue to work, you’ll just have to sign it yourself and configure the system to accept your signature during driver install. I understand that’s not ideal
I appreciate the feedback
sign it yourself and configure the system to accept your signature during driver install
Do you mean “enable test signing?” Or is there some other signing mechanism of which I’m unaware.
Real question, in case there’s any doubt. No sarcasm whatsoever implied.
Peter
Me, too. I was under the impression there we no longer ANY paths that enabled self-signed drivers, period.
@“Peter_Viscarola_(OSR)” said:
sign it yourself and configure the system to accept your signature during driver install
Do you mean “enable test signing?” Or is there some other signing mechanism of which I’m unaware.
Real question, in case there’s any doubt. No sarcasm whatsoever implied.
Peter
If there is some route other than “test signing” I would love to know. Using test signing will not pass most corporate IT requirements, so it’s not viable for out in the field.
@Zac_Lockard said:
INF directives/sections that will block signing are now tagged as such in the docs, such as https://learn.microsoft.com/en-us/windows-hardware/drivers/install/inf-logconfig-directive
You are able to edit the pages on Microsoft’s site? If so the caution is inaccurate from what I discovered. I tried to submit a driver with attestation signing for Win 10 only and it was bounced. Tech support told me that all drivers submitted not must pass infverif /k for Win 11 2H22, even if they are not targeted for Win 11.
That’s about the only real information tech support told me. The rest of it was all run around.
@rob18767 said:
The company is very hardware oriented. I’m am the entire software department.
After reading the rules (I do not work for FTDI) may I suggest
They do USB to serial (UART) converters in chip and cable form. They have their own drivers.
As long you know how a UART works this could be your ‘plug and play’ interface. Add this to a microcontroller and you may have a solution.
Back when I was working on the USB project I found a combined interface and microcontroller from Cypress that did everything we needed. Using the I/O pins of the chip I was able to drive the backplane bus in the external chassis just fine.
At the time there were multiple apps that accessed the hardware at the same time. These were written in the late 80s originally for Windows 1.0. Most of my work the last few years has been writing a multifunction app that replaces the multiple apps. I could get the hardware to work just fine with USB with one app running. When I tried with the multi-app suite I ran into problems. My assumption is that there was some sort of race problem going on and the FIFO on the controller was getting out of sync.
I have been campaigning to use a Raspberry Pi as the USB slave. It has a lot of advantages for debugging tools as well as future expansion. The systems engineer has some long term ideas about expanding the function of the microcontroller once its working.
@Bill_Olson said:
Back when I was working on the USB project I found a combined interface and microcontroller from Cypress that did everything we needed. Using the I/O pins of the chip I was able to drive the backplane bus in the external chassis just fine.At the time there were multiple apps that accessed the hardware at the same time. These were written in the late 80s originally for Windows 1.0. Most of my work the last few years has been writing a multifunction app that replaces the multiple apps. I could get the hardware to work just fine with USB with one app running. When I tried with the multi-app suite I ran into problems. My assumption is that there was some sort of race problem going on and the FIFO on the controller was getting out of sync.
I have been campaigning to use a Raspberry Pi as the USB slave. It has a lot of advantages for debugging tools as well as future expansion. The systems engineer has some long term ideas about expanding the function of the microcontroller once its working.
In low volumes Raspberry PI is fine apparently.
Avoid Arduino as you will run into potential licensing problems (as per linux). GPL sucks.
@“Peter_Viscarola_(OSR)” said:
sign it yourself and configure the system to accept your signature during driver install
Do you mean “enable test signing?” Or is there some other signing mechanism of which I’m unaware.
As far as I know, you can add the certificate that signed the driver to the trusted root certification authorities store on local system and then that certificate will be accepted, without test signing enabled.
@Bill_Olson said:
I tried to submit a driver with attestation signing for Win 10 only and it was bounced. Tech support told me that all drivers submitted not must pass infverif /k for Win 11 2H22, even if they are not targeted for Win 11.
The requirement was enforced in the Win11 22H2 HLK, and if you submit a driver through attestation you have to meet the INF requirements of the latest HLK regardless of targeting
@Zac_Lockard said:
The requirement was enforced in the Win11 22H2 HLK, and if you submit a driver through attestation you have to meet the INF requirements of the latest HLK regardless of targeting
So if IoT core is to replace CE… I guess we will meet that challenge when we come to it.
Is using Windows 10 IoT Enterprise LTSC 2021 a solution?
https://learn.microsoft.com/en-us/lifecycle/products/windows-10-iot-enterprise-ltsc-2021
@Mark_Roddy said:
yes, attestation signing requires a valid inf if you are signing a pnp ‘driver package’. You can get non pnp drivers attestation signed, I wonder if there is an approach there where you get your driver .sys file signed and then manually install it. The end goal is to get the stupid thing installed, not to pass the whql/attestation inf tests.
I believe that is the way to go and it works, at least for Windows 10/11 x86/x64 (may not work under Windows 11 on ARM64).
We do that for libusb-win32 kernel driver (libusb0.sys). The .sys driver got signed with attestation signing with a proper inf file with one valid VID/PID. Then the end user (of course with different VID/PID) can use Zadig or libusbK-inf-wizard (both are based on libwdi) to install the driver.
Somehow this mechanism does not work under Windows 11 on ARM64.
https://github.com/pbatard/libwdi/issues/289
@Zac_Lockard said:
As far as I know, you can add the certificate that signed the driver to the trusted root certification authorities store on local system and then that certificate will be accepted, without test signing enabled.
Just wondering if you know if this works under Windows 11 on ARM64. Thanks.
Reference discussion: libwdi/Zadig does not work under Windows 11 on ARM64.
https://github.com/pbatard/libwdi/issues/289
As far as I know, you can add the certificate that signed the driver to the trusted root certification authorities store on local system and then that certificate will be accepted, without test signing enabled.
Thank you for taking the time to reply, Mr. Lockard.
If that worked, there would be MUCH rejoicing in the driver development world. Consider all the military, medical, and process control drivers in the world where we could use this feature. I might even stop being cranky about the whole driver signing topic, if this were so.
Sadly, I have not seen it work in the past, and using Win11 22H2, I was not able to make this work:
To make this work, I’ve always had to enable Test Signing.
I would be very, very, happy to hear that I’m doing something wrong.
Thanks again,
Peter
I see in my snip I covered up the actual install status line. It reads:
!!! dvi: Device not started: Device has problem: 0x34 (CM_PROB_UNSIGNED_DRIVER), problem status: 0xc0000428.
That looks like the personal context. Is there a machine context as well?
That looks like the personal context. Is there a machine context as well?
Thank you, Mr. Barila… Rookie mistake, posting the personal context instead of the machine context!
Heres’s the machine context (the cert is THERE as well):
Installing your cert in trusted* was the documented and supported “release signed driver” method. That died when microsoft deprecated cross signed certs. Your driver can still be installed this way if and only if you signed it before the deprecation. Unless something changed in redmond, this path no longer exists. I’d be happy to be wrong.
Okay I will try again.
@“Peter_Viscarola_(OSR)” said:
Sadly, I have not seen it work in the past, and using Win11 22H2, I was not able to make this work:
Okay it does not work with Win 11 22H2
@“Peter_Viscarola_(OSR)” said:
Consider all the military, medical, and process control drivers in the world
Yes we do process control. The last thing you want with process control is for the drivers to stop working after an update right? Just like a large sign in kiosk mode beside a freeway.
Hence Microsoft developed Windows 10/11 IoT Enterprise LTSC. IoT being the new buzzword for embedded systems connected to the internet (We used to use Windows XP and 7 embedded). LTSC meaning ‘Long Term Service Channel’ in that any updates will not stop drivers from working.
(Also Windows IoT has cheaper licenses. I also see Windows IoT core is replacing Windows CE so you can expect some SBC devs over here).
So we do drivers for Windows 10 IoT Enterprise LTSC 2019
https://learn.microsoft.com/en-us/windows/iot/iot-enterprise/whats-new/windows-iot-enterprise-ltsc
Which is available until 2029 as version ‘17763’ (1809). This is what I develop with at work for now.
(Windows 10 IoT Enterprise LTSC 2021 is available until 2032!).
Can non-PnP drivers be signed and uploaded to the dashboard for these versions of Windows?
@“Peter_Viscarola_(OSR)” said:
To make this work, I’ve always had to enable Test Signing.
I would be very, very, happy to hear that I’m doing something wrong.
Thanks again,
Peter
As per my experience, as long as the .sys driver is Attestation signed, then you can create the driver package and use this method to install the driver package.
libwdi is using this method (it is just adding the on-the-fly generation of the certificate part).
https://github.com/pbatard/libwdi/wiki/FAQ#user-content-What_are_these_USBVID_PID_MI__Autogenerated_certificates_that_libwdi_installs_in_the_Trusted_certificate_stores
Catches: it does not seem to work under Windows 11 on ARM64.
