Dealing with Windows 64bit "I want SIGNED drivers!"

Solving 64-Bit Windows' "I Only Want Signed Drivers!" Tantrums

I love 64-bit Windows.  I love the ability to stick 8 gigs of RAM on a laptop, allowing me to run several virtual servers, each of which I can equip with 1.5 GB of RAM.  (Life's too short to wait for Server 2008 to get things done in 512 MB of RAM, y'know?)  I love how much snappier Adobe Lightroom is when it's no longer shackled to the 2 GB limits that 32-bit Windows requires.  And I especially love that the main problem with 64-bit Windows -- the lack of 64-bit drivers -- is largely a thing of the past, save for those cases where vendors use the new architecture as a way to force you to upgrade (and yes, I am talking to you, HP printer division and Cisco VPN folks).

Once in a while, though, I run up against the the thing that I most don't like about 64-bit Windows:  the iron rule of driver signing.  Ever since XP and 2003, the 64-bit versions of Windows have refused to load kernel executables or device drivers unless those executables and drivers are digitally signed.  Load a driver that's not signed, and 64-bit Windows pops up some scary-looking message essentially saying, "take a walk, buddy, and take your unsigned driver with you... I mean you don't really know where this thing's been, do you?"  You can get around it by pressing F8 every time you boot and disabling driver signing, but that's a pain.  There was once, briefly, a setting in bcdedit that would let you tell Windows to always skip driver signing, but Vista SP1 put an end to that -- and besides, I don't want Windows to ignore checking the signatures on all drivers, I just want it to allow me to run the occasional unsigned driver.

Look, I understand the whole thought process behind this totalitarian approach, which I understand runs something like this:

• Unsigned drivers cause the vast majority of Windows bluescreens.
  
• Unknowing users don't know that, and so blame Microsoft for blue screens
  
• This really irritates people at Microsoft and in particular Dave Cutler, Windows' Architectus Maximus
  
• Dave wants to make it easy to finger the culprit of any given blue screen
  
• Signing a driver carries with it something of a statement of personal confidence in that driver (and here, I feel, is where the whole thing falls down a bit:  signing a driver says you wrote it, not that it lacks bugs), so...
  
• 64-bit Windows requires that all drivers and kernel executables be signed.
  

It all just seems a bit heavy-handed for my taste -- sort of like, oh, say, scaring a large room full of people into thinking that you've just released a bunch of malaria-infected mosquitoes into the air to make a point about poverty.  Anyway, this month I wanted to offer a workaround for those who run 64-bit systems and really need to run an unsigned driver now and then.  The workaround?  Create your own driver signing certificate and sign the driver or application yourself!  Here are the steps.

Things to know before you build an OpenFiler SAN

These are some important tips that you may want to know before you go and choose the hardware that will run the OpenFiler software, if you do not want OpenFiler to be just a play toy:

1. Do not run OpenFiler on a desktop PC.
2. If you must use a desktop PC, use only Intel hardware (CPU, mainboard and network cards). Leave away any system that has nVidia, ATI, VIA or AMD hardware. The network cards can also be from Broadcom. Do not use network cards from Realtek, Marvell or others, put them on your usual desktops, not in your SAN.
3. Choose only "jumbo frames" enabled network cards from Intel/Broadcom. Search also for "teaming" or LACP or 802.3ad capable network cards. Do not forget that the switch also needs to know about these features.
4. Check all the chosen hardware against the RedHat HCL - https://hardware.redhat.com/. Do not use the hardware if is not on the RHEL HCL.
5. Do not use the latest and greatest of hardware, go for at least a year old hardware before the current kernel.
6. If you decide to buy some server (new or used), choose a server from a big server vendor: Dell, IBM, HP, Fujitsu-Siemens, Supermicro and others.
7. Do not use the RAID features implemented in chipset or add-on cards, expose every disk to the OpenFiler and use the software RAID implemented in OpenFiler. Buy simple add-on card for adding drives to the OpenFiler box, without RAID. If you do not find cards without RAID, disable the onboard RAID features.
8. For SCSI, use Adaptec, LSI Logic or AMI controllers. For SATA, use Silicon Image, Marvell or Intel AHCI controllers. Avoid JMicron and the likes.
9. Do not use USB or FireWire attached disk drives to use them as the main storage! Use them only for backup. Using OpenFiler on USB and FireWire disks will eventually result in tears.
10. Try to use SCSI/SAS disks. If you use SATA disks, use Seagate ES, Western Digital Enterprise/Raptor or Hitachi drives. If you must go with other brands/models, search for NCQ enabled drives.
11. Size your power supply carefully, SATA drives are particularly sensitive to voltage drops on the 12v rail. Choose a high quality and powerful PSU.
12. If you value your data, you must use a UPS on your OpenFiler system.
13. For the file system, use XFS. XFS is extremely resilient to faults, dirty shutdowns and other maladies that can cause data corruption.
14. Install Openfiler on a RAID1 set of drives, if one drive will fail your SAN will continue to work.

Keep in mind that OpenFiler is designed to store information. Sometimes very important information. Reliability is therefore the most important aspect of using OpenFiler, unless you don't mind losing data.