12:45 p.m.
On Wed, Nov 18, 2015 at 11:31:17PM -0500, Li Jin wrote:
> > > In any case the *.inf files don't seem to have any
distinguishing
> > > feature which would allow us to check this.
> > >
> > > Maybe this doesn't matter?
> >
> > Let me explain how it works:
> > We don't make any difference between server or client platforms when
> > building our drivers. Initially, all the files, mentioned above (inf,
> > cat, sys, and pdb), are absolutely the same. Then the files go to QE for
> > WHQL testing. QE tests the same drivers on both, desktop and server
> > platforms, and creates two different submissions files for sending them
> > to WHQL dashboard togather with the original "cat" file.
> > As the result, we have two different cat files created from the same
> > original one.
> >
> > As far as I remember, there shouldn't be any problem to swap these two
> > cat files, and use them interchangeable. But it will be better get some
> > conformation from QE team.
>
> Li Jin, this is a discussion we have on a public mailing-list regarding the
> files structure
> of our virtio-win distribution.
> Could you confirm Vadim's statement above?
Yes, I agree with Vadim's statement. The *.cat file is a signature file:
Before whql testing,the driver is only signed by redhat,when install driver in
guest,windows OS will prompt a security warning to confirm if customer want to install a
driver not signed by msft.
After whql testing and submit to msft,we will get a *.cat file signed by microsoft,which
will make driver installation smoothly(no extra warning).
The original *.cat file is same,whether the *.cat files are still same afer whql
submission depends on whether they are submit in one submission.
for example:
win8-64 and win2012 *.cat files are same because QE submit them in one submission(win8-64
and win2012 whql test both run on hck,results can be merged into one package);
win7-64 and win2008-64 *.cat files are different because we submit them in different
submissions(win7-64 whql test run on hck,win2008-64 run wlk,hck and wlk must submit
differently according to msft's strategy).
I tried swap cat files,drivers still can be installed correctly.
I went ahead and dug into this a little, and also talked to a colleague
who is involved in WHQL certification of drivers. Here's what I've got
(sorry if it's obvious for anyone; I failed to find any description of
it with just enough details).
Catalog files are pkcs7 containers with multi-layered nested ASN.1
structure; on Linux they are best viewed with with dumpasn1 (which,
unlike openssl asn1parse, recognizes most of the Microsoft objects).
They contain, in addition to signatures, a number of name:value pairs
with properties of the whole package, and a list of entries describing
every file in the package, with their own set of name:value pairs
representing the properties of those entries. In particular, for every
file a filename and an embedded (for PE images: exe, sys, dll) or
detached (for other files, e.g. inf) digest is stored, to match the file
to the record in the catalog.
For every file in the catalog theres an attribute named OSAttr; its
value is a string containing comma-separted list of Windows versions,
e.g. "2:5.1,2:5.2,2:6.0,2:6.1".
Besides, there's a global attribute "OS", containing comma-separated
list of Windows versions in a different format, e.g.
"XPX64,Server2003X64,VistaX64,Server2008X64,7X64,Server2008R2X64"
These are presumably the ones that have to be matched against the
version of the Windows the driver is installed into.
Both per-file OSAttr and global OS are populated when the catalog is
generated by inf2cat tool from Microsoft WDK
(https://msdn.microsoft.com/en-us/library/windows/hardware/ff553618(v=vs.8...),
which takes the list of values in its /os command-line parameter.
When the package is submitted for WHQL certification, MS regenerates the
the catalog with its own signature and leaving only those OSes in OSAttr
and OS for which certification is granted, and sends it back to the
submitter.
So it looks like yes, there's certain data in there which can be used to
match it against the exact Windows version; not sure what to do with all
this, though.
Roman.