[Qemu-devel] Impractical ideas?

[Qemu-devel] Impractical ideas?

[Robert Wittams]

Hi,

Having installed Win2k and various Linuxes under qemu, I've got all excited
at the potential of this project, and have been entertaining all kinds of
possibly impractical ideas... 

I was wondering if anyone had thought of using Qemu + a special kernel
module to do reverse engineering of binary or windows only drivers. 

I'm not sure if I'm missing something really obvious, but it seems like the
following should be possible:

Run a virtual machine in qemu with, for example, the binary nvidia drivers
on a linux system. On the host, a kernel module is configured that can
perform any operations on the hardware that are necessary (io writes and
dma, etc) and report interrupts to qemu. 

Run a series of OpenGL operations on the guest os, which will cause the
driver to do its hardware operations in qemu. These get passed on by qemu
to the kernel driver, which then performs them on the real hardware. 

This way, you would end up with knowledge of what the driver sends to the
card for any particular set of ( opengl state, card state, operation,
arguments.) It should even be possible to automatically create a
(ridiculous) opengl implementation that would work for the same exact set
of operations in the same order as the test run... and fail for anything
else ;-) 

How useful the information gleaned would be isn't clear to me (given eg how
hard it is to even understand the obfuscated free nvidia driver), and a GPU
is probably the most complex example to try to do this for due to the
sophistication of the drivers eg shader/ vertex program compilers etc. 
Maybe a network card driver would be more realistic. 

Another possibly hairy idea - A windows graphics driver that mirrors window
contents into separate X Windows ( or some windowing abstraction), allowing
a "rootless" integration of Win32 programs that don't run / run badly in
wine.. but I expect if this was at all easy, vmware would have done it by
now. Maybe this could be done in guest userspace, by just sending the
screen coordinates of all the windows to qemu, copying the screen area of
these to separate X windows, and just update them when possible.
. 
Rob

Re: [Qemu-devel] Impractical ideas?

[John R. Hogerhuis]

You are suggesting some kind of pass-through driver.

Some of the things you would have to configure for each instance of such
a driver would be:

The set of IO ports
The set of Interrupts to pass through
DMA stuff (knowledge deficit here), any kind of shared memory

So to even start you would have to track down this information from the
driver. I don't know much about windows drivers, but I suspect you could
gather some of this information from the driver itself, or resources it
registers when it is installed.

Of course there's no way you could share the device with the host OS
while running.

To me this sounds like more a job for Bochs, but I suppose the concept
is universally applicable.

That said I think it would be really hard. But if such a theoretical
device existed it would help you crack protocols better than just trying
to disassemble a driver, since you would get to see the back-and-forth
of the system in action. The equivalent of a network sniffer for APIs.

The "rootless window" issue has come up before, you can check the
archives. All that is left is design, implementation and testing ;-)...

-- John.

On Thu, 2004-05-06 at 09:08, Robert Wittams wrote:
> Hi,
> 
> Having installed Win2k and various Linuxes under qemu, I've got all excited
> at the potential of this project, and have been entertaining all kinds of
> possibly impractical ideas... 
> 
> I was wondering if anyone had thought of using Qemu + a special kernel
> module to do reverse engineering of binary or windows only drivers. 
> 
> I'm not sure if I'm missing something really obvious, but it seems like the
> following should be possible:
> 
> Run a virtual machine in qemu with, for example, the binary nvidia drivers
> on a linux system. On the host, a kernel module is configured that can
> perform any operations on the hardware that are necessary (io writes and
> dma, etc) and report interrupts to qemu. 
> 
> Run a series of OpenGL operations on the guest os, which will cause the
> driver to do its hardware operations in qemu. These get passed on by qemu
> to the kernel driver, which then performs them on the real hardware. 
> 
> This way, you would end up with knowledge of what the driver sends to the
> card for any particular set of ( opengl state, card state, operation,
> arguments.) It should even be possible to automatically create a
> (ridiculous) opengl implementation that would work for the same exact set
> of operations in the same order as the test run... and fail for anything
> else ;-) 
> 
> How useful the information gleaned would be isn't clear to me (given eg how
> hard it is to even understand the obfuscated free nvidia driver), and a GPU
> is probably the most complex example to try to do this for due to the
> sophistication of the drivers eg shader/ vertex program compilers etc. 
> Maybe a network card driver would be more realistic. 
> 
> Another possibly hairy idea - A windows graphics driver that mirrors window
> contents into separate X Windows ( or some windowing abstraction), allowing
> a "rootless" integration of Win32 programs that don't run / run badly in
> wine.. but I expect if this was at all easy, vmware would have done it by
> now. Maybe this could be done in guest userspace, by just sending the
> screen coordinates of all the windows to qemu, copying the screen area of
> these to separate X windows, and just update them when possible.
> . 
> Rob
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
> 
> 

Re: [Qemu-devel] Impractical ideas?

[J. Mayer]

On Thu, 2004-05-06 at 20:06, John R. Hogerhuis wrote:
> You are suggesting some kind of pass-through driver.
> 
> Some of the things you would have to configure for each instance of such
> a driver would be:
> 
> The set of IO ports
> The set of Interrupts to pass through
> DMA stuff (knowledge deficit here), any kind of shared memory

> So to even start you would have to track down this information from the
> driver. I don't know much about windows drivers, but I suspect you could
> gather some of this information from the driver itself, or resources it
> registers when it is installed.
> 

You just need to know the IRQ, IMHO:
you just have to check all accesses and print all IO, memory and DMA
requests that aren't handled by any devices. And for most devices, you
can parse the PCI descriptors and get the needed informations. 

> Of course there's no way you could share the device with the host OS
> while running.

You cannot share the device, but you may use it if the host OS doesn't.

> 
> To me this sounds like more a job for Bochs, but I suppose the concept
> is universally applicable.
> 
> That said I think it would be really hard. But if such a theoretical
> device existed it would help you crack protocols better than just trying
> to disassemble a driver, since you would get to see the back-and-forth
> of the system in action. The equivalent of a network sniffer for APIs.

Sounds right. But it may be possible to make a "false" driver that just
send the paquets that were sniffed from a guest OS. You'll never get a
real full working driver this way, but you may be able to control some
of the device resources...

> The "rootless window" issue has come up before, you can check the
> archives. All that is left is design, implementation and testing ;-)...
> 
> -- John.
> 
> On Thu, 2004-05-06 at 09:08, Robert Wittams wrote:
> > Hi,
> > 
> > Having installed Win2k and various Linuxes under qemu, I've got all excited
> > at the potential of this project, and have been entertaining all kinds of
> > possibly impractical ideas... 
> > 
> > I was wondering if anyone had thought of using Qemu + a special kernel
> > module to do reverse engineering of binary or windows only drivers. 
> > 
> > I'm not sure if I'm missing something really obvious, but it seems like the
> > following should be possible:
> > 
> > Run a virtual machine in qemu with, for example, the binary nvidia drivers
> > on a linux system. On the host, a kernel module is configured that can
> > perform any operations on the hardware that are necessary (io writes and
> > dma, etc) and report interrupts to qemu. 
> > 
> > Run a series of OpenGL operations on the guest os, which will cause the
> > driver to do its hardware operations in qemu. These get passed on by qemu
> > to the kernel driver, which then performs them on the real hardware. 
> > 
> > This way, you would end up with knowledge of what the driver sends to the
> > card for any particular set of ( opengl state, card state, operation,
> > arguments.) It should even be possible to automatically create a
> > (ridiculous) opengl implementation that would work for the same exact set
> > of operations in the same order as the test run... and fail for anything
> > else ;-) 
> > 
> > How useful the information gleaned would be isn't clear to me (given eg how
> > hard it is to even understand the obfuscated free nvidia driver), and a GPU
> > is probably the most complex example to try to do this for due to the
> > sophistication of the drivers eg shader/ vertex program compilers etc. 
> > Maybe a network card driver would be more realistic. 
> > 
> > Another possibly hairy idea - A windows graphics driver that mirrors window
> > contents into separate X Windows ( or some windowing abstraction), allowing
> > a "rootless" integration of Win32 programs that don't run / run badly in
> > wine.. but I expect if this was at all easy, vmware would have done it by
> > now. Maybe this could be done in guest userspace, by just sending the
> > screen coordinates of all the windows to qemu, copying the screen area of
> > these to separate X windows, and just update them when possible.
> > . 
> > Rob
> > 
> > 
> > 
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://mail.nongnu.org/mailman/listinfo/qemu-devel
> > 
> > 
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] Impractical ideas?

[John R. Hogerhuis]

Of course, there is already something in real life that can get you most
of this if you can afford to rent one: a logic analyzer with built-in
disassembler.

To buy one is *a lot* unless you get an old one like I have which is
only useful mainly for instrumenting older systems.

I guess we're getting really sci-fi now, but maybe you should just make
it pass-through everything to underlying OS, and the front end would be
a virtual logic analyzer.

Of course thinking about the cool timing diagrams a logic analyzer gives
you, I think I'm realizing what the real problem is here: timing.
Virtual drivers incorporate knowledge of timing of the real devices in
their operation.  Without that buffer between you and the bare metal, I
think the live guest driver just ain't gonna work. Counterarguments?

-- John.

Re: [Qemu-devel] Impractical ideas?

[Jason Gress]

On Thursday 06 May 2004 05:11 pm, John R. Hogerhuis wrote:
> Of course, there is already something in real life that can get you most
> of this if you can afford to rent one: a logic analyzer with built-in
> disassembler.
>
> To buy one is *a lot* unless you get an old one like I have which is
> only useful mainly for instrumenting older systems.
>
> I guess we're getting really sci-fi now, but maybe you should just make
> it pass-through everything to underlying OS, and the front end would be
> a virtual logic analyzer.
>
> Of course thinking about the cool timing diagrams a logic analyzer gives
> you, I think I'm realizing what the real problem is here: timing.
> Virtual drivers incorporate knowledge of timing of the real devices in
> their operation.  Without that buffer between you and the bare metal, I
> think the live guest driver just ain't gonna work. Counterarguments?
>
I hate to feed the fire ;), but it would seem that drivers couldn't use too 
much timing information as they can never expect a certain time for anything.  
Example: If I had a 50MHz FSB, won't most PCI cards still work even though 
most systems run at 66MHz?  (Think old Pentiums)  Also I would think that in 
the case of, say a PCI Gigabit ethernet or HDD controller hogging the 
bandwidth on a PCI bus that a video card (or whatever) would still work 
properly even though the delays may go up on a 'real' system in those cases.  
So, in conclusion, I would think that timing may not be all 'that' 
important.  ;)

> -- John.
>
	Jason
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Impractical ideas?

[John R. Hogerhuis]

Perhaps not. I'm used to dealing with constained systems though.

Try bit-banging a port without having the timing be deterministic.

But you may have a point on desktops. I'm no expert on the PCI bus.

-- John.

On Thu, 2004-05-06 at 18:34, Jason Gress wrote:
> I hate to feed the fire ;), but it would seem that drivers couldn't use too 
> much timing information as they can never expect a certain time for anything.  

Re: [Qemu-devel] Impractical ideas?

[David Woodhouse]

On Thu, 2004-05-06 at 17:08 +0100, Robert Wittams wrote:
> Hi,
> 
> Having installed Win2k and various Linuxes under qemu, I've got all excited
> at the potential of this project, and have been entertaining all kinds of
> possibly impractical ideas... 
> 
> I was wondering if anyone had thought of using Qemu + a special kernel
> module to do reverse engineering of binary or windows only drivers. 
> 
> I'm not sure if I'm missing something really obvious, but it seems like the
> following should be possible:
> 
> Run a virtual machine in qemu with, for example, the binary nvidia drivers
> on a linux system. On the host, a kernel module is configured that can
> perform any operations on the hardware that are necessary (io writes and
> dma, etc) and report interrupts to qemu. 

Someone was muttering the other day about the possibility of putting
qemu in the kernel and using it to run i386 binary-only modules in
non-i386 host kernels.

I think it's a sick idea, but I might look at it anyway. After all, it's
no worse than running the ACPI crap in an interpreter.

-- 
dwmw2

Re: [Qemu-devel] Impractical ideas?

[Irvin Probst]

On Fri, 2004-05-07 at 11:44, David Woodhouse wrote:
>
> Someone was muttering the other day about the possibility of putting
> qemu in the kernel and using it to run i386 binary-only modules in
> non-i386 host kernels.
> 
> I think it's a sick idea, but I might look at it anyway. After all, it's
> no worse than running the ACPI crap in an interpreter.

Powerbook owners are gonna love you if it works for their airport
extreme wifi cards (broadcom). Of course using linuxppc + kqemu +
ndiswrapper + a windows driver is a bit crazy...

-- 
Irvin Probst
There are 10 types of people in the world... those who understand binary
and those who don't.

Re: [Qemu-devel] Impractical ideas?

[Chad Page]

	Well, you *could* add qemu to ndiswrapper and make a powerpc
version.  Matching up code for disparate kernels would be incredibly
difficult - if ndiswrapper itself is native PPC it's much more likely to
work!

	- Chad


On Fri, 7 May 2004, Irvin Probst wrote:

> On Fri, 2004-05-07 at 11:44, David Woodhouse wrote:
> >
> > Someone was muttering the other day about the possibility of putting
> > qemu in the kernel and using it to run i386 binary-only modules in
> > non-i386 host kernels.
> > 
> > I think it's a sick idea, but I might look at it anyway. After all, it's
> > no worse than running the ACPI crap in an interpreter.
> 
> Powerbook owners are gonna love you if it works for their airport
> extreme wifi cards (broadcom). Of course using linuxppc + kqemu +
> ndiswrapper + a windows driver is a bit crazy...
> 
> -- 
> Irvin Probst
> There are 10 types of people in the world... those who understand binary
> and those who don't.
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
> 

Re: [Qemu-devel] Impractical ideas?

[David Woodhouse]

On Fri, 2004-05-07 at 10:51 -0700, Chad Page wrote:
> 	Well, you *could* add qemu to ndiswrapper and make a powerpc
> version.  Matching up code for disparate kernels would be incredibly
> difficult - if ndiswrapper itself is native PPC it's much more likely to
> work!

Of course -- I wouldn't want to think about running non-native _Linux_
code. With NDIS you have a clearly foreign ABI already, and fairly
well-defined calls in and out of the Windows code. That's _definitely_
the way you'd do it.

Probably starting with hacking up qemu to the point that it can call
simple i386 functions in-kernel, then trying to fudge that into
ndiswrapper.

-- 
dwmw2