Hi Stan and folks, I'd like to clarify a few things about how Win 2008 driver signings works.
There are two kinds of signatures that would be needed by users of the WinOF release. 1) Driver binary signing on 64-bit platforms. Windows 2008 (and Vista) will not load kernel code that doesn't have an embedded digital signature in the binary. This is NOT a WHQL signature, this a digital signature created by the developer using a "acceptable" certificate. Acceptable certificates come from companies like Verisign. A developer signs the binaries using this certificate along with what's know as a cross certificate from Microsoft. There is a cross certificate for every acceptable certificate vendor and basically tells the OS the certificate vendor is valid for driver binary signing. This cross certificate comes from Microsoft and is signed with the key for the master driver signing certificate, which is built into the OS. The purpose of this signature is to keep unknown/untraceable code out of kernel mode, which makes finding the source of virus code much easier. Virus writers are less inclined to leave breadcrumbs that trace back to them too. Verisign certificates are something like $400/year and you need to be an acceptable "organization" to the company issuing the code signing certificate. For Verisign, last I hear, this generally means you need to be a corporation in the US. Other acceptable code certificate sources may have other policies. As part of the driver signing process, a timestamp signature is also included; to validate the signing was done during the period the code signing certificate was valid, which allows the signature to still be valid after the original certificate expires. 2) For driver installation, it's desirable for security catalog files (.cat) need to have a digital signature of a "trusted" entity. WHQL is one trusted entity, but in Windows 2008, a system administrator can also designate other trusted certificates. For example, the same Verisign certificate used for kernel binary signing can be set as trusted. I don't offhand remember if self signed certificates can be trusted or not. Once the OS is told to trust a certificate, device installation can occur in a secure process with no user interaction, just like WHQL signed installations in Windows 2003. I believe it's also possible to add a certificate as trusted in the domain controller, and as part of domain group policy have that certificate be automatically available to any/all domain machines. The ability to designate arbitrary certificates as trusted in Windows 2008 is very different than Windows 2003, where the ONLY certificates trusted for driver install are from WHQL. So, the end result is that if a valid kernel code signing certificate can be obtained, it should be usable to fully sign both the kernel binaries and the installer security catalog. No WHQL testing of any kind is required to do this signing. This is all documented in the WDK/Microsoft.com. The kernel binary signature is not optional, and if there is a WinOF binary release, it will have to be signed to work on Windows 2008. If there is only a source release, then whoever builds the binaries would have to sign things. End users could also just obtain a valid signing certificate and sign the binaries and security catalogs. Organizations like corporations/universities/governments agencies should not have a problem qualifying for a code signing certificate. Some organizations will want WHQL certification on things; because it means a certain minimal level of quality testing has been done. For Windows 2003 currently, and quite possibly for Windows 2008, using WHQL signed drivers also impacts Microsoft's OS support policies. Generally, if you are running any non-WHQL signed drivers, Microsoft's OS support will not be free and have no guarantee of solving problems (they basically will charge for their support time). Also note there is also a program to get WHQL signatures in an unclassified device category. These allow silent install under W2K3 (and W2K8). The unclassified WQHL signatures are NOT WHQL certification, and it's unclear if unclassified WHQL signing improves Microsoft support policies. I'm personally in favor of the kernel code signing requirements in Windows 2008, as I believe it will help reduce viruses and other malware. I also believe (as do others), that the inflexible security catalog signing required by Windows 2003 is problematic, and Windows 2008 resolves much of the problem. Jan Terboven, Christian wrote: > Hi there. > > We are evaluating Windows Server 2008 and are experiencing problems > with InfiniBand. We tried both 1.0 and 1.0.1 using the steps > described below, without success. Will there be a signed distribution > in the not too distant future? > > If not, what would you propose for a rather large (Intel-based) > installation? Manually patching every machine is not an option. > Hello, The OFA/WWG (OpenFabrics Alliance/Windows Working Group) is working with Microsoft on a driver signing solution for WinOF. Windows Server 2008 (LongHorn) support is targeted for the March'08 WinOF 1.1 release. The problem is that the optimal out-of-box LH experience w.r.t. driver signing is based on WHQL certification. Although the source code from which WinOF drivers are built from has been WHQL'ed, the WinOF release itself is not WHQL'ed; OFA/Windows is not a hardware vendor. MS is working on a driver signing solution for SW organizations which distribute hardware drivers. Unfortunately WinOF does not have a LH solution at this time; a 'signed' proprietary vendor IB stack may be your short term answer. Stan. > > Kind regards, > Christian > > > > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im Auftrag von Tzachi Dar > Gesendet: Montag, 8. Oktober 2007 23:29 > An: Smith, Stan > Cc: [email protected] > Betreff: [ofw] RE: Windows Server 2008 (Beta) fails to load x64 > mthca.sys ? > > In two words error 39 means that the files are not signed. > > The simplest way to workaround this problem is to boot the computer > with F8 pressed and to select a working mode that doesn't force driver > signing. > > After that I believe that you might be able to install manually but > the installation using devmon will still fail. > > You can avoid this failure by replacing devmon with the following > command: > DPInst.exe /SW /SA /PATH "path_to_inf" > > Dpinst is part of the vista DDK (version 6000), and has a good help > with it. > > I'll send a longer update about the different ways to sign the files. > > Thanks > Tzachi > >> -----Original Message----- >> From: Smith, Stan [mailto:[EMAIL PROTECTED] >> Sent: Monday, October 08, 2007 10:52 PM >> To: Tzachi Dar >> Cc: [email protected] >> Subject: Windows Server 2008 (Beta) fails to load x64 mthca.sys ? >> >> Hello, >> Might you be able to diagnose the mthca.sys failure; my >> previous understanding from email was that you have been able >> to load the openib-windows stack on Windows Server 2008 successfully. >> >> Failure to load is witnessed when installed via WIX (CA: >> devman.exe) or by hand via Device Manger install. >> WIX installer installs same x64 drivers files on Windows >> Server 2003 with no problems; WIX or Device Manager? >> >> Windows Server 2008, LongHorn (LH for now), claims a >> corrupted mthca.sys driver (code 39) as does the Infiniband >> Fabric system device. Again, these same files load >> successfully on Windows Server 2003. >> >> .cdf files for mthca.inf and ib_bus.inf are in the same >> folder as the .inf files for the install. >> >> All files are svn.849. >> >> Suggestions? >> >> Thanks, >> >> Stan. >> >> Infiniband Driver Properties-> General-tab >> >> Windows cannot load the device driver for this hardware. The >> driver may be corrupted or missing. (Code 39). >> >> From System events viewer - PNP event >> >> Log Name: System >> Source: Microsoft-Windows-User-PnP >> Date: 10/8/2007 11:32:23 AM >> Event ID: 20001 >> Task Category: None >> Level: Information >> Keywords: >> User: SYSTEM >> Computer: CSE1 >> Description: >> Driver Management concluded the process to install driver >> FileRepository\mthca.inf_2483b5f7\mthca.inf for Device >> Instance ID >> PCI\VEN_15B3&DEV_6278&SUBSYS_627815B3&REV_A0\4&25BDA1CD&0&0030 >> with the following status: 0. >> Event Xml: >> <Event >> xmlns="http://schemas.microsoft.com/win/2004/08/events/event";> >> <System> <Provider Name="Microsoft-Windows-User-PnP" >> Guid="{eea178e3-e9d4-41ca-bb56-cede1a476629}" /> >> <EventID>20001</EventID> <Version>0</Version> >> <Level>4</Level> >> <Task>0</Task> >> <Opcode>0</Opcode> >> <Keywords>0x8000000000000000</Keywords> >> <TimeCreated SystemTime="2007-10-08T18:32:23.502Z" /> >> <EventRecordID>607</EventRecordID> >> <Correlation /> >> <Execution ProcessID="2596" ThreadID="2464" /> >> <Channel>System</Channel> >> <Computer>CSE1</Computer> >> <Security UserID="S-1-5-18" /> >> </System> >> <UserData> >> <InstallDeviceID >> xmlns:auto-ns2="http://schemas.microsoft.com/win/2004/08/events"; >> xmlns="http://manifests.microsoft.com/win/2004/08/windows/userpnp";> >> >> <DriverName>FileRepository\mthca.inf_2483b5f7\mthca.inf</DriverName> >> <DriverVersion>1.0.0.847</DriverVersion> >> <DriverProvider>OpenIB Alliance</DriverProvider> >> >> <DeviceInstanceID>PCI\VEN_15B3&DEV_6278&SUBSYS_627815B >> 3&REV_ A0\4&25BDA1CD&0&0030</DeviceInstanceID> >> <SetupClass>{58517E00-D3CF-40C9-A679-CEE5752F4491}</SetupClass> >> <RebootOption>false</RebootOption> >> <UpgradeDevice>false</UpgradeDevice> >> <IsDriverOEM>true</IsDriverOEM> >> <InstallStatus>0</InstallStatus> >> <DriverDescription>InfiniHost (MT25208) - Mellanox >> InfiniBand HCA for PCI Express</DriverDescription> >> </InstallDeviceID> >> </UserData> >> </Event> >> > _______________________________________________ > ofw mailing list > [email protected] > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
