linux-kernel - Re: incorrect taint of ndiswrapper

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 27 Oct 2006 11:53:30 -0400
From:	Pavel Roskin <proski@....org>
To:	Roland Kuhn <rkuhn@....physik.tu-muenchen.de>
Cc:	Adrian Bunk <bunk@...sta.de>, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org
Subject: Re: incorrect taint of ndiswrapper

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@...ts.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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/