From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932488AbcHJXze (ORCPT ); Wed, 10 Aug 2016 19:55:34 -0400 Received: from gate.crashing.org ([63.228.1.57]:43474 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932245AbcHJXzc (ORCPT ); Wed, 10 Aug 2016 19:55:32 -0400 Message-ID: <1470873296.3015.117.camel@kernel.crashing.org> Subject: Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access From: Benjamin Herrenschmidt To: Alexander Duyck Cc: Alexey Kardashevskiy , Bjorn Helgaas , Hannes Reinecke , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Babu Moger , Paul Mackerras , Alex Williamson , santosh@chelsio.com, Netdev Date: Thu, 11 Aug 2016 09:54:56 +1000 In-Reply-To: References: <1452684335-46107-1-git-send-email-hare@suse.de> <1452684335-46107-4-git-send-email-hare@suse.de> <20160209210458.GB32530@localhost> <1470787409.3015.81.camel@kernel.crashing.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.4 (3.20.4-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2016-08-10 at 08:47 -0700, Alexander Duyck wrote: > > The problem is if we don't do this it becomes possible for a guest to > essentially cripple a device on the host by just accessing VPD > regions that aren't actually viable on many devices.  And ? We already can cripple the device in so many different ways simpy because we have pretty much full BAR access to it... > We are much better off > in terms of security and stability if we restrict access to what > should be accessible.  Bollox. I've heard that argument over and over again, it never stood and still doesn't. We have full BAR access for god sake. We can already destroy the device in many cases (think: reflashing microcode, internal debug bus access with a route to the config space, voltage/freq control ....). We aren't protecting anything more here, we are just adding layers of bloat, complication and bugs. > In this case what has happened is that the > vendor threw in an extra out-of-spec block and just expected it to > work. Like vendors do all the time in all sort of places I still completely fail to see the point in acting as a filtering middle man. > In order to work around it we just need to add a small function > to drivers/pci/quirks.c that would update the VPD size reported so > that it matches what the hardware is actually providing instead of > what we can determine based on the VPD layout. > > Really working around something like this is not much different than > what we would have to do if the vendor had stuffed the data in some > reserved section of their PCI configuration space. It is, in both cases we shouldn't have VFIO or the host involved. We should just let the guest config space accesses go through. >   We end up needing > to add special quirks any time a vendor goes out-of-spec for some > one-off configuration interface that only they are ever going to use. Cheers, Ben.