From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751574AbbJHFdw (ORCPT ); Thu, 8 Oct 2015 01:33:52 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:37655 "EHLO mail-wi0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750707AbbJHFdv (ORCPT ); Thu, 8 Oct 2015 01:33:51 -0400 Subject: Re: [PATCH v3 2/3] uio_pci_generic: add MSI/MSI-X support To: "Michael S. Tsirkin" References: <20151005094932.GA5236@kroah.com> <56124EDB.3070701@scylladb.com> <20151006143821.GA11541@redhat.com> <5613DE26.1090202@cloudius-systems.com> <20151006174648-mutt-send-email-mst@redhat.com> <5613E75E.1040002@scylladb.com> <1444157480.4059.67.camel@redhat.com> <5614C11B.6090601@scylladb.com> <1444235464.4059.169.camel@redhat.com> <56154AB4.1050509@scylladb.com> <20151007230553-mutt-send-email-mst@redhat.com> Cc: Alex Williamson , Vlad Zolotarov , Greg KH , linux-kernel@vger.kernel.org, hjk@hansjkoch.de, corbet@lwn.net, bruce.richardson@intel.com, avi@cloudius-systems.com, gleb@cloudius-systems.com, stephen@networkplumber.org, alexander.duyck@gmail.com From: Avi Kivity Message-ID: <56160039.4090901@scylladb.com> Date: Thu, 8 Oct 2015 08:33:45 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151007230553-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.