linux-kernel - Re: [PATCH v3 2/3] uio_pci_generic: add MSI/MSI-X support

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]

Message-ID: <56160039.4090901@scylladb.com>
Date:	Thu, 8 Oct 2015 08:33:45 +0300
From:	Avi Kivity <avi@...lladb.com>
To:	"Michael S. Tsirkin" <mst@...hat.com>
Cc:	Alex Williamson <alex.williamson@...hat.com>,
	Vlad Zolotarov <vladz@...udius-systems.com>,
	Greg KH <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, hjk@...sjkoch.de, corbet@....net,
	bruce.richardson@...el.com, avi@...udius-systems.com,
	gleb@...udius-systems.com, stephen@...workplumber.org,
	alexander.duyck@...il.com
Subject: Re: [PATCH v3 2/3] uio_pci_generic: add MSI/MSI-X support



On 08/10/15 00:05, Michael S. Tsirkin wrote:
> On Wed, Oct 07, 2015 at 07:39:16PM +0300, Avi Kivity wrote:
>> That's what I thought as well, but apparently adding msix support to the
>> already insecure uio drivers is even worse.
> I'm glad you finally agree what these drivers are doing is insecure.
>
> And basically kernel cares about security, no one wants to maintain insecure stuff.
>
> So you guys should think harder whether this code makes any sense upstream.

You simply ignore everything I write, cherry-picking the word "insecure" 
as if it makes your point.  That is very frustrating.

The kernel is not secure against root, even in the restricted "will it 
oops" sense.  You can oops it easily, try dd if=/dev/urandom of=/dev/mem 
(or of=/dev/sda for a more satisfying oops).

> Getting support from kernel is probably the biggest reason to put code
> upstream, and this driver taints kernel unconditionally so you don't get
> that.

The biggest reason is that if a driver gets upstream, in a year or two 
it is universally available.


> Alternatively, most of the problem you are trying to solve is for
> virtualization - and it is is better addressed at the hypervisor level.
> There are enough opensource hypervisors out there - work on IOMMU
> support there would be time well spent.

It is not.  The problem we are trying to solve, and please consider the 
following as if written in all caps, is that some configurations do not 
have an iommu or cannot use it for performance reasons.

It is good practice to defend against root oopsing the kernel, but in 
some cases it cannot be achieved.  A trivial example is a nommu kernel, 
this is another.  In these cases we can give up on this goal, because it 
is not the only reason for the kernel's existence, there are others.
--
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/