linux-kernel - Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.

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: <1452269236.31901.46.camel@redhat.com>
Date:	Fri, 08 Jan 2016 11:07:16 -0500
From:	Mark Salter <msalter@...hat.com>
To:	Mark Rutland <mark.rutland@....com>
Cc:	linaro-acpi@...ts.linaro.org, linux-pci@...r.kernel.org,
	will.deacon@....com, okaya@...eaurora.org, wangyijing@...wei.com,
	Lorenzo.Pieralisi@....com, Tomasz Nowicki <tn@...ihalf.com>,
	ddaney@...iumnetworks.com, linux-acpi@...r.kernel.org,
	robert.richter@...iumnetworks.com,
	linux-arm-kernel@...ts.infradead.org, catalin.marinas@....com,
	arnd@...db.de, Stefano.Stabellini@...citrix.com,
	Liviu.Dudau@....com, bhelgaas@...gle.com, tglx@...utronix.de,
	mw@...ihalf.com, jcm@...hat.com, jchandra@...adcom.com,
	rjw@...ysocki.net, linux-kernel@...r.kernel.org,
	hanjun.guo@...aro.org, Suravee.Suthikulpanit@....com,
	jiang.liu@...ux.intel.com
Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors
 against platfrom specific quirks.

On Fri, 2016-01-08 at 15:12 +0000, Mark Rutland wrote:
> On Fri, Jan 08, 2016 at 03:01:37PM +0000, Mark Rutland wrote:
> > On Fri, Jan 08, 2016 at 09:16:21AM -0500, Mark Salter wrote:
> > > On Wed, 2015-12-16 at 16:16 +0100, Tomasz Nowicki wrote:
> > > > Some platforms may not be fully compliant with generic set of PCI config
> > > > accessors. For these cases we implement the way to overwrite accessors
> > > > set before PCI buses enumeration. Algorithm that overwrite accessors
> > > > matches against platform ID (DMI), domain and bus number, hopefully
> > > > enough for all cases. All quirks can be defined using:
> > > > DECLARE_ACPI_MCFG_FIXUP() and keep self contained.
> > > > 
> > > > example:
> > > > 
> > > > static const struct dmi_system_id yyy[] = {
> > > >         {
> > > >                 .ident = "<Platform ident string>",
> > > >                 .callback = <handler>,
> > > >                 .matches = {
> > > >                         DMI_MATCH(DMI_SYS_VENDOR, "<system vendor>"),
> > > >                         DMI_MATCH(DMI_PRODUCT_NAME, "<product name>"),
> > > >                         DMI_MATCH(DMI_PRODUCT_VERSION, "product version"),
> > > >                 },
> > > >         },
> > > >         { }
> > > > };
> > > > 
> > > 
> > > This seems awkward to me in the case where the quirk is SoC-based and there
> > > may be multiple platforms affected. Needing a DECLARE_ACPI_MCFG_FIXUP for
> > > each platform using such a SoC (i.e. Mustang and Moonshot) doesn't seem
> > > right. In that case, I think it'd be better to check CPUID and possibly
> > > some SoC register to cover all platforms affected.
> > 
> > CPUs get reused across SoCs, so as you've implicitly noted, the CPUID
> > alone is insufficient.
> > 
> > Given that IP blocks get moved around between SoC variants, I don't
> > think you can check "some SoC register" based on the CPU ID -- you can
> > end up bringing the board down at that point.
> > 
> > If the CPU ID alone is insufficient to tell you about a component, it
> > cannot give you enough information about a component you can use to
> > query more information from.
> > 
> > If your platform requires a quirk, it's always going to be painful (and
> > to some extent, rightfulyl so). We should aim for correctness here with
> > explicit matching.
> 
> Further, if there is going to be an ever-expanding set of platforms
> requring quirks, then we need a standard mechanism in ACPI to enable the
> platform to tell us explicitly either which specific PCI implementation
> is used, or which common quirk is necessary.
> 

No, an ever-expanding set is exactly what we don't want. I think you've convinced
me that I'm taking a wrong view of the problem. Putting something in the ACPI
standard would be going too far and I think a hard sell to the standards folk.
There really is no foolproof way to match a plug and play ACPI PCIe root to
specific hardware without considering the exact platform and/or BIOS info. So
yeah, it should be painful in order to give incentive to the silicon vendors to
get it right.