linux-kernel - Re: [PATCH V5 3/4] x86/PCI: Stop enabling ECS for AMD CPUs after Fam16h

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]

Date:	Fri, 23 May 2014 07:01:41 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Robert Richter <rric@...nel.org>
Cc:	Suravee Suthikulanit <suravee.suthikulpanit@....com>,
	Borislav Petkov <bp@...en8.de>,
	Daniel J Blueman <daniel@...ascale.com>,
	Andreas Herrmann <herrmann.der.user@...glemail.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Aravind Gopalakrishnan <Aravind.Gopalakrishnan@....com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	Borislav Petkov <bp@...e.de>,
	Myron Stowe <myron.stowe@...hat.com>
Subject: Re: [PATCH V5 3/4] x86/PCI: Stop enabling ECS for AMD CPUs after Fam16h

On Fri, May 23, 2014 at 5:56 AM, Robert Richter <rric@...nel.org> wrote:
> On 22.05.14 20:54:54, Bjorn Helgaas wrote:
>> I'm going to go out on a limb and guess that Windows does not enable
>> ECS, so it probably uses ECAM.  Therefore, I suspect Linux's parsing
>> of MCFG is broken in some way, and we probably *could* use ECAM in all
>> these cases I'm seeing.
>
> Even if ECS is not enabled the system should be fine anyway, as ECS is
> only used to enable certain features. For family 10h this was
> originally the IBS EILVT (extended interrupt local vector table,
> needed for hw profiling) setup which need to be set by the OS which
> the BIOS didn't right. This should be fixed now and properly set by
> the BIOS on 15h+ systems.
>
> I don't remember what was added to 16h where ECS was needed, I think
> there was one (Suravee?). Not sure if this is essential.
>
> So using MCFG should be fine, since if in the rare case when it is
> broken, the system should work properly anyway without it and only
> some special features, if any, do not work anymore (e.g. IBS should
> work fine).

[I guess I've been using the wrong term here.  I think "ECS" just
refers to the extended config space itself, and I should have been
saying "IO ECS" or "EnableCf8ExtCfg".]

My understanding was that if we don't enable IO ECS and we don't have
MCFG, we will not be able to access extended config space.  The system
can certainly boot without extended config space, but some drivers may
not work correctly, so it would be a regression from the user point of
view.

The case where MCFG is broken may be rare, but I still want to avoid
the regression.  And my guess is that the MCFG is not really broken in
these cases, because I suspect Windows is using it.  Our MCFG parsing
code is a mess, and I suspect that we are claiming MCFG is broken when
it really isn't.

If I understand correctly, IO ECS is also limited to domain 0, so if
we have multiple PCI host bridges, i.e., multiple PNP0A03/PNP0A08
devices, and we want them in different domains, we'd have to use ECAM.

Bjorn
--
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/