From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754300AbbJHIdA (ORCPT ); Thu, 8 Oct 2015 04:33:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37568 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754261AbbJHIc4 (ORCPT ); Thu, 8 Oct 2015 04:32:56 -0400 Date: Thu, 8 Oct 2015 11:32:50 +0300 From: "Michael S. Tsirkin" To: Avi Kivity 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 Subject: Re: [PATCH v3 2/3] uio_pci_generic: add MSI/MSI-X support Message-ID: <20151008104212-mutt-send-email-mst@redhat.com> References: <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> <56160039.4090901@scylladb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56160039.4090901@scylladb.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 08, 2015 at 08:33:45AM +0300, Avi Kivity wrote: > 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. And I'm sorry about the frustration. I didn't intend to twist your words. It's just that I had to spend literally hours trying to explain that security matters in kernel, and all I was getting back was a summary "there's no security issue because there are other way to corrupt memory". So I was glad when it looked like there's finally an agreement that yes, there's value in validating userspace input and yes, it's insecure not to do this. > It is good practice to defend against root oopsing the kernel, but in some > cases it cannot be achieved. I originally included ways to fix issues that I pointed out, ranging from harder to implement with more overhead but more secure to easier to implement with less overhead but less secure. There didn't seem to be an understanding that the issues are there at all, so I stopped doing that - seemed like a waste of time. For example, will it kill your performance to reset devices cleanly, on open and close, protect them from writes into MSI config, BAR registers and related capablities etc etc? And if not, why are you people wasting time arguing about that? The only thing I heard is that it's a hassle. That's true (though if you follow my advice and try to share code with vfio/pci you get a lot of this logic for free). So it's an understandable argument if you just need something that works, quickly. But if it's such a stopgap hack, there's no need to insist on it upstream. -- MST