none
Microsft not digitally signing Hyper-V drivers

    Question

  • Hi Everyone

    I came accross a troubling problem today while performing a disaster recovery test. I restored a Windows 2008 Enterprise x64 VM from backup and on boot after restoring C: drive, System State & Shadow Copy Components I got a error "storflt.sys - Windows cannot verify the digital signature". So I booted off Windows 2008 DVD ISO, accessed command prompt, renamed the original storflt.sys driver that Backup Exec had replaced with the restored one and restarted again. The system then happily booted with this version of the driver

    After some investigfation I found that version that had been restored was newer than the one installed with Windows and was not digially signed like the original. After some more digging I tracked this new unsigned file to KB950050 - The RTM version of Hyper-V. The digtally signed version was from the RC version of Hyper-V included with Windows 2008. I also found another patch with a newer version again of storflt.sys - KB956710. Once again this driver was not digitally signed.

    So the question is why isn't MS digitally signing their own drivers? Especially considering how x64 Windows really wants drivers signed. I could understand a non regression tested hotfix or beta driver not being signed but the RTM version of Hyper-V 's drivers not being signed I find perplexing.

    Any thoughts on this? I'm just glad I didn't come across this when doing a DR for real. Now to find out why Backup Exec 12 SP3 took 3.5 hours to restore the system state.
    Wednesday, February 25, 2009 1:18 PM

Answers

  • Hi,

    The drivers (storflt.sys) is catalog signed, not signed individually.

    Please run SIGVERIF command on your Hyper-V machine, and you will get the following result of storflt.sys.

    storflt.sys              2008/6/11      2:5.1,2:5.2,2:6.0   Signed              Package_7_for_KB9500Microsoft Windows

    Best regards,
    Vincent Hu

    Friday, February 27, 2009 6:07 AM

All replies

  • With Microsoft, it is often "Do as I say and not as I do".
    Wednesday, February 25, 2009 10:03 PM
  • bnborg said:

    With Microsoft, it is often "Do as I say and not as I do".



    I have been in the industry long enough to definetly know that statement to be true. I had been under the impression MS had been trying to mend their ways in this respect but alas - it's not true.

    I sent a email to the Virtulisation team through their blog yesterday with the same information as in my thread and a "please explain".

    The drivers not being signed isn't really an issue for me technically - my DR procedure now has an extra step to it. It's just more of a pain and adds more complexity to what should be a simple procedure and extra stress if I ever actually have to implement the DR procedure.

    I'm still having issues with Backup Exec speed restoring the system state too, 3.5 hours for 10GB. This is around 90MB per minute towards the end of the restore. Once the system state was restored and the server back up it took less time to restore 195GB of exchange stores (3 hours) than the system state. Going to investigate BMR with Backup Exec's IDR option to see if I can improve things. From inital research I'm not the only one expriencing slow performance with VSS on Windows 2008.

    Friday, February 27, 2009 12:57 AM
  • Hi,

     

    It sounds like you have a catalog problem, as that driver shows as signed on all my systems, and our SE process does not allow us to ship unsigned drivers AFAIK. It is signed, something happened to your configuration, quite possibly the replacement file nuked the old catalog which means simply bringing the old file back might not bring the catalog (that contains the information verifying it’s signed) back at the same time.

     

    In addition, if you have any problem with Backup Exec, I recommend that you contact Symantec for more information.

     

     

    Best regards,

    Vincent Hu

    Friday, February 27, 2009 1:40 AM
  • Vincent Hu said: 

     

    It sounds like you have a catalog problem, as that driver shows as signed on all my systems, and our SE process does not allow us to ship unsigned drivers AFAIK. It is signed, something happened to your configuration, quite possibly the replacement file nuked the old catalog which means simply bringing the old file back might not bring the catalog (that contains the information verifying it’s signed) back at the same time.



    While I was testing to locate the source of the unsigned driver I did a clean install of Windows 2008 Enterprise x64. I checked the storflt.sys file at that point - it's signed. I then installed KB950050. After a reboot I checked storflt.sys - it's not signed. What version of that driver do you have? The version I have after installing KB950050 is 6.0.6001.18016. I can see digital signatures on other files in the system32\drivers directory like storvsp.sys.
    Friday, February 27, 2009 3:19 AM
  • Hi,

    The drivers (storflt.sys) is catalog signed, not signed individually.

    Please run SIGVERIF command on your Hyper-V machine, and you will get the following result of storflt.sys.

    storflt.sys              2008/6/11      2:5.1,2:5.2,2:6.0   Signed              Package_7_for_KB9500Microsoft Windows

    Best regards,
    Vincent Hu

    Friday, February 27, 2009 6:07 AM
  • Hi Vincent,

    Can you provide a little more detail about what do you mean when you say a driver is "catalog signed".  I've never heard this terminology before and don't understand the significance of it.

    Also you wrote: "quite possibly the replacement file nuked the old catalog".  How do I discover the catalog that is associated with this driver, storflt.sys?

    I have a similar situation as the original writer, a disaster recovery of a hyper-V machine is not successful because of "storflt.sys - Windows cannot verify the digital signature".

    Thanks for more explanation.

    Friday, April 10, 2009 6:44 PM
  • Hi TCarruthers,

     

    To sign a file or a group of files via a Catalog file involves a bit more work then just signing a file.  To sign using a Catalog file we first need to identify what files we want signed?  Next we need to produce a “CDF” file for these files.  A CDF file is a text file that lists information necessary to create a catalog file, such as the name of the Catalog file, Encoding Type, Public Version, Catalog attributes, OS attributes (what OS will this catalog be valid for), and lastly the location of each of the files that will be a member of the catalog file.  Also we need to consider what OS we are building this CDF file for.  For example, if we are working with Windows 98 the CDF needs to have a file name as the "tag";  if we are working with Windows 98SE or Windows 2000 the CDF uses the hash of the file as the "tag".

     

    Once the CDF file is completed we can build the Catalog file by simply using Makecat in the following method.  (MAKECAT c:\testsig\TEST.CDF)  this will create a Test.CAT in the same directory.  Now we have a catalog file that contains hash’s for all the members.  Next we need to sign the catalog file.  This is done in exactly the same way that we signed the file itself.  Please refer to the previous section for instruction on signing the catalog file.

     

     

    Best regards,

    Vincent Hu

    Monday, April 13, 2009 4:34 AM
  • So if creating a catalog involves are a bit of work why use them? Why not just sign each file like it was with the Windows 08 shipping version?

    Also as it's a signed catalog, is the patch doing something in the background to stop windows complaining about the file not being signed during boot? 
    Tuesday, April 14, 2009 11:50 AM
  • Hi,

     

    According to the description, the issue seems to be related to Driver Development. As we mainly focus on the general question about Windows Server system and here is not the best support resource for Driver Development, it is recommend you to get further support in the corresponding community so that you can get the most qualified pool of respondents. Thanks for your understanding.

     

    For your convenience, I have list the related link as followed.

     

    MSDN Forums

    http://social.msdn.microsoft.com/Forums/

     

    MSDN Forums

    http://forums.microsoft.com/msdn/default.aspx?siteid=1

     

    In addition, I also include some articles about Digital Signatures, please refer to:

     

    Introduction to Code Signing

    http://msdn.microsoft.com/en-us/library/ms537361.aspx

     

    Digital Signatures

    http://msdn.microsoft.com/en-us/library/aa906322.aspx

     

     

    Best regards,

    Vincent Hu

    Wednesday, April 15, 2009 7:58 AM
  • So... 
    Basically this is a Microsoft issue?

    Tuesday, October 25, 2011 4:49 PM