Re: incorrect taint of ndiswrapper

[Pavel Roskin <proski@gnu.org>]

Hi Roland,

On Fri, 2006-10-27 at 14:52 +0200, Roland Kuhn wrote:

> Maybe everyone would be more happy if this "completely different API"  
> would live at lower priviledge level, e.g. ring 1, so it could not  
> screw up kernel internals? Is this technically possible? Maybe it's  
> the same thing, but another way could be to run NDIS stuff inside a  
> xen-like virtual environment... Has anyone tried yet?

I think it would be better to move this discussion to ndiswrapper
<ndiswrapper-general@lists.sourceforge.net>

I'm not familiar with the fine details of ndiswrapper implementation and
neither am I good at understanding memory management in Linux, but I
suspect it's not worth the trouble.

I believe there is no "ring 1" on x86_64 (unless it's in i386
compatibility mode).  So it would work on i386 only.  Maybe x86_64 could
use its "ring 3" equivalent, i.e. standard userspace permissions, but I
don't think it would be what you want.

Even on i386, I don't see an easy way to allocate executable memory with
ring 1 permissions.  See include/asm-i386/pgtable.h.

I suspect that there is no support for running kernel code at anything
but "ring 0".  What do you think are the chances that support for
low-privileged kernel code will be added to the kernel just for
ndiswrapper?  I think the chances are pretty slim.

In the case of the PCI driver, some critical operations would have to be
passed to the NDIS driver, such as IRQ and DMA processing.  It would be
better to make sure that the code has the necessary priority to do it
fast and correctly.

In the case of the USB driver, it may be better to go all the way to the
standard userspace.  This would require a protocol to pass network API
to the userspace, including wireless extensions.  I believe the work is
underway.

-- 
Regards,
Pavel Roskin