Unmodified driver reuse and Afterburner

[Valery V. Sedletski]

I'm contributing to an OS/2 cloning project (www.osFree.org) and there is some hope to reuse unmodified
Linux device drivers. Here, the L4Ka Unmodified driver reuse and Afterburner projects seem to be very
promising. But I still have some questions that are not clear. So, can someone answer the questions regarding
these technologies?

1)  The web page about Unmodified driver reuse project states that Linux drivers are unmodified. Does that
mean that they are unmodified in their _source_code_ form, but recompilation is required? Or, they remain
unmodified in their binary form? (Is there a possibility to be binary compatible with native Linux?)

2)   As I understand, Linux drivers are platform-neutral. So, they are probably do not work with hardware
directly, but instead, call routines in architecture-specific part of kernel, which operate hardware directly.
So, only architecture-specific part of kernel must be modified to paravirtualize Linux kernel. And drivers remain
untouched. (Maybe, even no recompilation required). Am I right?

3)  Is the unmodified driver reuse project and L4Ka virtualisation technologies all Linux or UNIX specific?
Does they rely on some Linux features (drivers platform neutrality etc.). Or, is it possible to reuse unmodified
Windows drivers? If there is a possibility to paravirtualise ReactOS kernel by using Afterburner project, then, is
a source code for Windows device drivers required?

4)  Must be the Operating System sources, for which Afterburner is applied to, to be 32-bit clean, or they
(sources) can contain 16-bit code? (Maybe, it is possible to use Afterburner with OS/2 sources? These
sources contain 16-bit parts along with 32-bit ones)

5)  What are "virtualisation-sensitive" instructions, modified by afterburner? Are they just privileged instructions
or something else?

6)  The Device Driver Reuse project is based on the mapper application inside Device driver OS (DD/OS).
The Client OS calls this mapper and it translates this request into the form, specific to DD/OS kernel. The
question is: is the individual support for each reused device driver required in this mapper, or the mapper is
"driver-independent"? How can this be made (driver independence)? The ioctl requests to different drivers are
different, so, it seems that the specific support is required in mapper for each driver. (In other words, there is
support in mapper for HDD driver and LAN card driver, for example. But if we want to add a new driver to
DD/OS, must the mapper be modified or not? So, must the mapper support each driver specifically (is this
support hardcoded in mapper), or is it general for different drivers?)

Thanks in advance,
WBR,
Valery

[Valery V. Sedletski]

On Wed, 20 Jun 2007 20:21:13 +0200, Kim-Thomas Moeller wrote:

>Most Linux driver source code is processor independent. Unfortunately,
>some architecure-specific kernel functions that contain sensitive
>instructions are inlined into driver code (e.g. in, out).
>

But, as I understand, usermode task can issue IN or OUT instructions. -- It can obtain I/O rights from
some hardware manager (like l4io in l4env), they are just mapped as i/o flexpages. And if flexpages are mapped into
task i/o address space, the task can do i/o on these ports directly. Am I not right?

>> 3)  Is the unmodified driver reuse project and L4Ka virtualisation technologies all Linux or UNIX specific?
>> Does they rely on some Linux features (drivers platform neutrality etc.). Or, is it possible to reuse unmodified
>> Windows drivers? If there is a possibility to paravirtualise ReactOS kernel by using Afterburner project, then, is
>> a source code for Windows device drivers required?
>
>Both techniques, driver reuse and L4Ka virtualization, are applicable to
>any ordinary OS. However, only Linux implementations are publicly
>available. I guess cross-OS driver reuse is possible.
>

But, the problem of source code availability for all device drivers remains, doesn't it? So, it is "theoretically"
posiible to apply this approach to windows drivers, but in practice, the inavailability of their source code prevents
this approach from working?

>> 4)  Must be the Operating System sources, for which Afterburner is applied to, to be 32-bit clean, or they
>> (sources) can contain 16-bit code? (Maybe, it is possible to use Afterburner with OS/2 sources? These
>> sources contain 16-bit parts along with 32-bit ones)
>
>As far as I know, the afterburner currently assumes 32-bit protected
>mode for the kernel. Support of 16-bit user code depends on the
>hypervisor used.
>

So, in case of L4 as a hypervisor, it is not possible to execute 16-bit code? Or, some possibility exists? For example, Adam
Lackorzynsky on l4-hackers@... mailing list, says, that in case of Fiasco, there is a possibility to reserve
some GDT slots for usermode tasks. (this may be useful for creating 16-bit segments descriptors) -- Maybe some way exists, to
adapt Afterburner approach to mixed 16-bit/32-bit code?

And does anybody know about mapper application, is the special support for each "reused" device driver needed in this
mapper?
>6)
>The Device Driver Reuse project is based on the mapper application inside Device driver OS (DD/OS).
>The Client OS calls this mapper and it translates this request into the form, specific to DD/OS kernel. The
>question is: is the individual support for each reused device driver required in this mapper, or the mapper is
>"driver-independent"? How can this be made (driver independence)? The ioctl requests to different drivers are
>different, so, it seems that the specific support is required in mapper for each driver. (In other words, there is
>support in mapper for HDD driver and LAN card driver, for example. But if we want to add a new driver to
>DD/OS, must the mapper be modified or not? So, must the mapper support each driver specifically (is this
>support hardcoded in mapper), or is it general for different drivers?)

[Joshua LeVasseur]

On Jun 20, 2007, at 2:09 PM, Valery V. Sedletski wrote:

> I'm contributing to an OS/2 cloning project (www.osFree.org) and  
> there is some hope to reuse unmodified
> Linux device drivers. Here, the L4Ka Unmodified driver reuse and  
> Afterburner projects seem to be very
> promising. But I still have some questions that are not clear. So,  
> can someone answer the questions regarding
> these technologies?
>
> 1)  The web page about Unmodified driver reuse project states that  
> Linux drivers are unmodified. Does that
> mean that they are unmodified in their _source_code_ form, but  
> recompilation is required? Or, they remain
> unmodified in their binary form? (Is there a possibility to be  
> binary compatible with native Linux?)

With para-virtualization, the driver source code is unchanged, but  
you must recompile.  With pre-virtualization, you can use binaries  
that execute both on raw hardware and in the VM.  So if binary  
compatibility is necessary (because you don't have the source code  
for the driver), then you can achieve it if you convince the driver's  
vendor to run the pre-virtualization tools for you.  Potentially in  
the long run that will happen automatically due to Linux's  
paravirt_ops project.

>
> 2)   As I understand, Linux drivers are platform-neutral. So, they  
> are probably do not work with hardware
> directly, but instead, call routines in architecture-specific part  
> of kernel, which operate hardware directly.
> So, only architecture-specific part of kernel must be modified to  
> paravirtualize Linux kernel. And drivers remain
> untouched. (Maybe, even no recompilation required). Am I right?

Drivers use inlined functions and macros, so on some level they will  
change, and will thus require recompilation.  For Linux, this  
particularly concerns enabling/disabling interrupts, saving the  
interrupt status, and spin locks (which maybe disable interrupts).


> 3)  Is the unmodified driver reuse project and L4Ka virtualisation  
> technologies all Linux or UNIX specific?
> Does they rely on some Linux features (drivers platform neutrality  
> etc.). Or, is it possible to reuse unmodified
> Windows drivers? If there is a possibility to paravirtualise  
> ReactOS kernel by using Afterburner project, then, is
> a source code for Windows device drivers required?

The technologies are not Linux/UNIX specific.  Both Intel and  
Microsoft use the approach for reusing Windows drivers in VMs in  
their research projects.  VMware has always done something similar  
for their hosted hypervisor.

You probably could reuse unmodified Windows drivers if you have some  
source-code base that conforms to the driver API (maybe that is  
ReactOS?).  I don't know whether Windows drivers access privileged  
instructions.  If they do, you'd just have to be willing to do some  
more heavy weight virtualization.   You'd probably only need to  
virtualize the interrupt flag, and even that might be possible using  
the x86 virtual interrupt flag.  And with newer chips you have the  
option to run the Windows drivers in VT domains.

> 4)  Must be the Operating System sources, for which Afterburner is  
> applied to, to be 32-bit clean, or they
> (sources) can contain 16-bit code? (Maybe, it is possible to use  
> Afterburner with OS/2 sources? These
> sources contain 16-bit parts along with 32-bit ones)

The current Afterburner has no support for 16-bit code.  It probably  
could be adapted to 16-bit code.

> 5)  What are "virtualisation-sensitive" instructions, modified by  
> afterburner? Are they just privileged instructions
> or something else?

Virtualization-sensitive instructions are a superset of the  
privileged instructions.  Only the privileged instructions cause  
traps that permit a VMM to virtualize the OS.  The problem is that  
x86 has many system instructions that user-level can execute, and  
which will return unexpected data to a guest OS, because the  
instructions offer the VMM no chance to intercede and fix up the  
data.  Newer chips from Intel and AMD have special virtualization  
modes that fix the problem.

>
> 6)  The Device Driver Reuse project is based on the mapper  
> application inside Device driver OS (DD/OS).
> The Client OS calls this mapper and it translates this request into  
> the form, specific to DD/OS kernel. The
> question is: is the individual support for each reused device  
> driver required in this mapper, or the mapper is
> "driver-independent"? How can this be made (driver independence)?  
> The ioctl requests to different drivers are
> different, so, it seems that the specific support is required in  
> mapper for each driver. (In other words, there is
> support in mapper for HDD driver and LAN card driver, for example.  
> But if we want to add a new driver to
> DD/OS, must the mapper be modified or not? So, must the mapper  
> support each driver specifically (is this
> support hardcoded in mapper), or is it general for different drivers?)

The mapper is specific to a class of drivers, and like any driver  
modularization, it provides a lowest common denominator for the  
devices' features.  If a new device comes along with features that  
exceed the abstractions of the OS or of the mapper, then one must  
update all layers to take advantage of those new features.  You don't  
have to update the mapper to support each new device in a particular  
device class.



Josh

[Valery V. Sedletski]

On Fri, 22 Jun 2007 14:11:55 +0200, Joshua LeVasseur wrote:

Thank you very much for answering so thoroughly to my questions.

>
>
>> 3)  Is the unmodified driver reuse project and L4Ka virtualisation  
>> technologies all Linux or UNIX specific?
>> Does they rely on some Linux features (drivers platform neutrality  
>> etc.). Or, is it possible to reuse unmodified
>> Windows drivers? If there is a possibility to paravirtualise  
>> ReactOS kernel by using Afterburner project, then, is
>> a source code for Windows device drivers required?
>
>The technologies are not Linux/UNIX specific.  Both Intel and  
>Microsoft use the approach for reusing Windows drivers in VMs in  
>their research projects.  VMware has always done something similar  
>for their hosted hypervisor.
>

But, these Microsoft/Intel/VMWare technologies are not L4-specific, aren't they? These
technologies are probably, Xen or VMWare specific. The question remains, can these
technologies be adopted to other hypervisors, like L4...

>
>You probably could reuse unmodified Windows drivers if you have some  
>source-code base that conforms to the driver API (maybe that is  
>ReactOS?).

Yes, ReactOS is the Opensource Windows NT clone, aiming at binary compatibility
with windows applications and drivers (http://www.reactos.org/)

> I don't know whether Windows drivers access privileged  
>instructions.  If they do, you'd just have to be willing to do some  
>more heavy weight virtualization.   You'd probably only need to  
>virtualize the interrupt flag, and even that might be possible using  
>the x86 virtual interrupt flag.  And with newer chips you have the  
>option to run the Windows drivers in VT domains.
>

But are these possibilities (using Virtual Interrupt Flag and VT domains with newer AMD and
Intel processors) open to L4 applications?

>
>> 5)  What are "virtualisation-sensitive" instructions, modified by  
>> afterburner? Are they just privileged instructions
>> or something else?
>
>Virtualization-sensitive instructions are a superset of the  
>privileged instructions.  Only the privileged instructions cause  
>traps that permit a VMM to virtualize the OS.  The problem is that  
>x86 has many system instructions that user-level can execute, and  
>which will return unexpected data to a guest OS, because the  
>instructions offer the VMM no chance to intercede and fix up the  
>data.  Newer chips from Intel and AMD have special virtualization  
>modes that fix the problem.
>

So, as I understood, just privileged instructions cause traps, which
are handled by Wedge. Wedge (aka VMM) handles a TRAP, correcting
the result of an instruction, which caused this trap. And for the trap to be handled
successfully, the virtualization-sensitive instruction must be patched (the afterburner
adds extra space after the instruction, by NOP'ping, and during the OS loading, this
place is patched by Wedge), if it is not patched, then this cause the TRAP to be
handled unsuccessfully. So, the "unauthorized" code of an OS in VM differs from
"authorized" one in that it is not patched, and, so, the traps caused by these instructions
are handled unsuccessfully, so, such a program just traps (or "segfaults", in other words).
Am I right?

>
>>
>> 6)  The Device Driver Reuse project is based on the mapper  
>> application inside Device driver OS (DD/OS).
>> The Client OS calls this mapper and it translates this request into  
>> the form, specific to DD/OS kernel. The
>> question is: is the individual support for each reused device  
>> driver required in this mapper, or the mapper is
>> "driver-independent"? How can this be made (driver independence)?  
>> The ioctl requests to different drivers are
>> different, so, it seems that the specific support is required in  
>> mapper for each driver. (In other words, there is
>> support in mapper for HDD driver and LAN card driver, for example.  
>> But if we want to add a new driver to
>> DD/OS, must the mapper be modified or not? So, must the mapper  
>> support each driver specifically (is this
>> support hardcoded in mapper), or is it general for different drivers?)
>
>The mapper is specific to a class of drivers, and like any driver  
>modularization, it provides a lowest common denominator for the  
>devices' features.  If a new device comes along with features that  
>exceed the abstractions of the OS or of the mapper, then one must  
>update all layers to take advantage of those new features.  You don't  
>have to update the mapper to support each new device in a particular  
>device class.
>

And how then the mapper determines, that the driver belongs to a certain
device class? Is this done by writing a class for each driver in some config
file? Or, the mapper just examines, what devices are in the system, and
which drivers operate which device, and so, determining the class of a driver
by the class of a device it operates?

>
>
>Josh
>
>

[Bernhard Pöss]

If I understand you right you want to reuse Windows drivers inside ReactOS.
Did you ever think of reusing Linux drivers?
Do you want to reuse the drivers in user mode or in kernel mode?
Depending on these choices you should choose the technology you use.

-Bernhard

On 6/24/07, Valery V. Sedletski <_valerius@...> wrote:

> On Fri, 22 Jun 2007 14:11:55 +0200, Joshua LeVasseur wrote:
>
> Thank you very much for answering so thoroughly to my questions.
>
> >
> >
> >> 3)  Is the unmodified driver reuse project and L4Ka virtualisation
> >> technologies all Linux or UNIX specific?
> >> Does they rely on some Linux features (drivers platform neutrality
> >> etc.). Or, is it possible to reuse unmodified
> >> Windows drivers? If there is a possibility to paravirtualise
> >> ReactOS kernel by using Afterburner project, then, is
> >> a source code for Windows device drivers required?
> >
> >The technologies are not Linux/UNIX specific.  Both Intel and
> >Microsoft use the approach for reusing Windows drivers in VMs in
> >their research projects.  VMware has always done something similar
> >for their hosted hypervisor.
> >
>
> But, these Microsoft/Intel/VMWare technologies are not L4-specific, aren't they? These
> technologies are probably, Xen or VMWare specific. The question remains, can these
> technologies be adopted to other hypervisors, like L4...
>
> >
> >You probably could reuse unmodified Windows drivers if you have some
> >source-code base that conforms to the driver API (maybe that is
> >ReactOS?).
>
> Yes, ReactOS is the Opensource Windows NT clone, aiming at binary compatibility
> with windows applications and drivers (http://www.reactos.org/)
>
> > I don't know whether Windows drivers access privileged
> >instructions.  If they do, you'd just have to be willing to do some
> >more heavy weight virtualization.   You'd probably only need to
> >virtualize the interrupt flag, and even that might be possible using
> >the x86 virtual interrupt flag.  And with newer chips you have the
> >option to run the Windows drivers in VT domains.
> >
>
> But are these possibilities (using Virtual Interrupt Flag and VT domains with newer AMD and
> Intel processors) open to L4 applications?
>
> >
> >> 5)  What are "virtualisation-sensitive" instructions, modified by
> >> afterburner? Are they just privileged instructions
> >> or something else?
> >
> >Virtualization-sensitive instructions are a superset of the
> >privileged instructions.  Only the privileged instructions cause
> >traps that permit a VMM to virtualize the OS.  The problem is that
> >x86 has many system instructions that user-level can execute, and
> >which will return unexpected data to a guest OS, because the
> >instructions offer the VMM no chance to intercede and fix up the
> >data.  Newer chips from Intel and AMD have special virtualization
> >modes that fix the problem.
> >
>
> So, as I understood, just privileged instructions cause traps, which
> are handled by Wedge. Wedge (aka VMM) handles a TRAP, correcting
> the result of an instruction, which caused this trap. And for the trap to be handled
> successfully, the virtualization-sensitive instruction must be patched (the afterburner
> adds extra space after the instruction, by NOP'ping, and during the OS loading, this
> place is patched by Wedge), if it is not patched, then this cause the TRAP to be
> handled unsuccessfully. So, the "unauthorized" code of an OS in VM differs from
> "authorized" one in that it is not patched, and, so, the traps caused by these instructions
> are handled unsuccessfully, so, such a program just traps (or "segfaults", in other words).
> Am I right?
>
>
> >
> >>
> >> 6)  The Device Driver Reuse project is based on the mapper
> >> application inside Device driver OS (DD/OS).
> >> The Client OS calls this mapper and it translates this request into
> >> the form, specific to DD/OS kernel. The
> >> question is: is the individual support for each reused device
> >> driver required in this mapper, or the mapper is
> >> "driver-independent"? How can this be made (driver independence)?
> >> The ioctl requests to different drivers are
> >> different, so, it seems that the specific support is required in
> >> mapper for each driver. (In other words, there is
> >> support in mapper for HDD driver and LAN card driver, for example.
> >> But if we want to add a new driver to
> >> DD/OS, must the mapper be modified or not? So, must the mapper
> >> support each driver specifically (is this
> >> support hardcoded in mapper), or is it general for different drivers?)
> >
> >The mapper is specific to a class of drivers, and like any driver
> >modularization, it provides a lowest common denominator for the
> >devices' features.  If a new device comes along with features that
> >exceed the abstractions of the OS or of the mapper, then one must
> >update all layers to take advantage of those new features.  You don't
> >have to update the mapper to support each new device in a particular
> >device class.
> >
>
> And how then the mapper determines, that the driver belongs to a certain
> device class? Is this done by writing a class for each driver in some config
> file? Or, the mapper just examines, what devices are in the system, and
> which drivers operate which device, and so, determining the class of a driver
> by the class of a device it operates?
>
> >
> >
> >Josh
> >
> >
>
>
>
>

[Valery V. Sedletski]

On Mon, 25 Jun 2007 23:05:38 -0700, Bernhard Poess wrote:

>If I understand you right you want to reuse Windows drivers inside ReactOS.

No, I am trying to develop an open source OS/2 clone. ReactOS is opensource WinNT clone, and allows
to use unmodified windows drivers and applications, if we try to port ReactOS to L4, for example, using
the same approach as with L4Linux (using Afterburner project).

>Did you ever think of reusing Linux drivers?
>Do you want to reuse the drivers in user mode or in kernel mode?
>Depending on these choices you should choose the technology you use.

I thought about reusing Linux drivers, by using a technique of L4Ka Afterburner project. But I also asked if it
possible to apply this approach to windows drivers. In the case of Linux a kind of paravirtualization (named
pre-virtualization) is used. I asked if this technique is applicable to ReactOS and unmodified windows drivers. I
want, of course, to use windows drivers de-privileged (in user mode). The answer was that recompilation is
needed, and so, the sources for drivers must be available. And also it was said, that some "more
heavy-weight" virtualization technology could be needed, such as one involving Interrupt flag virtualization.

>
>-Bernhard
>