interesting

Not trying to discourage you from experimenting with parsing PE headers from code running in the kernel

No?

I am.

Bad idea. What are you trying to accomplish by doing this?

Peter

Isn't there a better option for small companies like us?

and

I wish there was a simpler option for smaller companies like us than an EV cert.

@henrik_meida C'mon... Send some emails, make some phone calls. It'll take you less time to talk to a couple of EU-based CAs than it takes you to repeatedly complain here about how hard you think it might be for you to get an EV Cert.

Folks have been complaining about this here in the Community for years. What it comes down to is people need to stop complaining and spend some time doing their homework. There are lots of things involved with running a business that are like this -- That's life in the 21st Century, right?

The guidelines that any CA has to follow to be able to issue an EV Cert are here. You'll note that there's nothing here about the size of the business, or the business having an Internet presence. OSR is a business as small as yours... we never had even the tiniest bit of trouble with the EV Cert process.

The "trick" is how any given CA operationalizes these guidelines. IOW, what does the CA require from you to demonstrate to them that "the Subject... legally exists as a valid organization or entity". THAT's why you need to talk to somebody knowledgeable at the CA.

Certum's policies (just to randomly choose one that I know is in the EU, again... I know nothing about this particular CA) are here. You'll see that they require your company name, address, the name of the incorporating or registering entity, your registration number. They need to also verify that whoever is signing the EV contract is authorized to do so.

Seriously... those are tasks that any business should be able to undertake without undo burden. Get your General Manager or his/her admin to do some work, and you should be fine. Once it's done, it's done, and you don't have to worry about it again.

Peter

@Richard_M said:
So what is our best option right now for purchasing an EV certificate for signing our drivers such that they successfully load in all versions of windows (regardless of secure boot), without going through Microsoft Hardware Dev Center program? We actually contacted Digicert, and they said "You can still purchase a code signing certificate with Digicert but you can no longer order certificates with Kernal-mode driver signing capabilities"..

Right now the best choice seems to be getting a certificate from a CA, that has cross-certificate expiration date beyond Apr 2021. Entrust is the most looked at, since their life term is the longest (Jul 2025). However, I'm not sure if anybody confirmed yet, that they indeed provide a certificate able to sign the drivers with that cross-certificate...

But if you aim for "all versions of windows (regardless of secure boot)", then you already have no choice, but to use Microsoft's services. Because Windows 10/2016 with Secure Boot enabled require the drivers to be at least Attestation signed by Microsoft, and do not accept drivers signed by anybody else (bar a few special situations), not even with an EV certificate. The EV in this case is required for signing the package that you're sending to Microsoft, but not the drivers themselves, and cross-certificate is not needed for it.

IMHO when presented requirements like this, the very first question you should ask is how can i split this work into a UM service.

while it is possible to do these kinds of things in KM, it will be difficult in the extreme. String manipulation you can roll your own without too much trouble, but calling a web service from KM would be a massive amount of work

But the point is that the security requirement is the issue and not the OS. Simple security requirements can be met simply. Complex security requirements are complex. The devices and the USB protocol are the same under any OS.

There are probably some kinds of things that are easier to do under one OS versus another. But it's probably not fundamental to your problem.

Taking a SWAG, I would say that you have bad requirements. And what you need to do is recapitulate them in technically sound terms instead - easier said than done I know. A requirement change that I advocated for in 2009 was just recently approved. And that was a simple missing negation in a financial regulation calculation. And they didn't even have to get the law amended - just a better interpretation of this obscure case. Of course it helped that now is the only time in the last 20+ years that the case applies and they were facing financial loss because of the wrong arithmetic

Try to think logically. If all threads have explicitly entered the wait state by means of calling WaitForMultipleObjects() , who is going to release them ( I am making certain assumptions here -more on it below )????

Your assumptions refute your own assertion. I stand by my original statement, and I'm not sure why you're arguing. Most apps spend the majority of their time with all threads in a wait state. The main thread is waiting for something to pop into the message queue. Some threads wait on timers. Some threads wait on network activity. Some are thread pools waiting for work. It is a very common condition for a Windows application.