Xen users - May 2009 - Disabling driver signature enforcement for Windows DomUs

Hi all,

After loading the GplPV drivers for Windows Server 2008, I wanted to  
get rid of the annoying F8 option when rebooting each time.  I looked  
at Ready Driver Plus, which seemed to work, but was only a  
workaround.  It also seemed to kill my terminal connection from Dom0.   
After some research, I found another way:

http://www.ngohq.com/home.php?page=dseo

Which will disable driver signature enforcement.  Also, it''s  
reversible too.  Here''s a breakdown of what I did:

- started with clean install of Windows Server 2008 Enterprise (64-bit)
- installed latest GplPV drivers, verified everything was working with  
the driver enforcement enabled at each boot
- as per DSEO instructions, disabled all User Account Controls via  
windows secpol.msc snap-in
- installed DSEO and enabled test mode
- reboot
- GplPV drivers came up disabled, so I reinstalled the GplPV drivers,  
then ran DSEO and test singed each xen file under C:\Windows 
\system32\drivers which was about 4 files total
- reboot
- OS booted up without prompting for driver enforcement override
- re-enabled the User Account Controls, and rebooted to verify that  
everything was still working

I''d be curious to know if this works or not for anyone else.  For now,
I''m moving on to do more tests on my windows DomU, and hoping that I  
can put the driver enforcement issue behind me.

...adam






_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Thu, May 7, 2009 at 12:37 AM, Adam Wead <awead@indiana.edu>
wrote:
>  Here''s a breakdown of what I did:
>
> - started with clean install of Windows Server 2008 Enterprise (64-bit)
> - installed latest GplPV drivers, verified everything was working with the
> driver enforcement enabled at each boot
Which version did you use?
I tried 0.10.0.47, then upgrading to 0.10.0.55 (which SHOULD be safe),
but ended up destroying my Windows installation :P
Good thing it was a test instance. That''s part of the reason why most
of my Windows deployment still use 0.9.12-pre13 (at least until I can
test a safe way to upgrade them).
> - as per DSEO instructions, disabled all User Account Controls via windows
> secpol.msc snap-in
> - installed DSEO and enabled test mode
> - reboot
> - GplPV drivers came up disabled, so I reinstalled the GplPV drivers, then
That''s the weird part. GPLPV should already be signed with James
Harper''s certificate (and looking at file properties tells me that).
But as it is, on my last test xen-vbd works but xen-net does not.
> ran DSEO and test singed each xen file under C:\Windows\system32\drivers
> which was about 4 files total
I wonder what they use for testsign. AFAIK Windows 2008 SDK''s file
(which is the "official" way to do testsigning) can''t be
partially
redistibuted. Did they use openssl?
> - reboot
> - OS booted up without prompting for driver enforcement override
> - re-enabled the User Account Controls, and rebooted to verify that
> everything was still working
>
> I''d be curious to know if this works or not for anyone else.  For
now, I''m
> moving on to do more tests on my windows DomU, and hoping that I can put
the
> driver enforcement issue behind me.
Thanks for the info.

Regards,

Fajar

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> > - as per DSEO instructions, disabled all User Account Controls via
windows
> > secpol.msc snap-in
> > - installed DSEO and enabled test mode
> > - reboot
> > - GplPV drivers came up disabled, so I reinstalled the GplPV
drivers, then
> 
> That''s the weird part. GPLPV should already be signed with James
> Harper''s certificate (and looking at file properties tells me
that).
> But as it is, on my last test xen-vbd works but xen-net does not.
> 
I still can''t figure it out. I right click on the .sys file and go
properties and it tells me that there is a signature there, but then
according to device manager it isn''t signed, for both the network and
disk. I think the disk driver loads because it loads early enough that
windows can''t figure out that it isn''t signed yet. The network
driver
obviously loads later and so windows can do its thing then. XenPci
appears to be signed as far as Windows is concerned.

One thing that puzzles me is that in device manager it says that the
drivers for xennet are xennet.sys and xenpci.sys. I don''t understand
why
xenpci.sys is mentioned there. 

I''ll ask on the ntdev list. There has been a heap of discussion there
about signing though, so I expect they''re sick of the questions :)

James

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users