linux-kernel - Re: [Xen-devel] [PATCH] xen/pci: try to reserve MCFG areas earlier

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:   Tue, 10 Sep 2019 21:36:58 +0100
From:   Igor Druzhinin <igor.druzhinin@...rix.com>
To:     Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        <xen-devel@...ts.xenproject.org>, <linux-kernel@...r.kernel.org>
CC:     <jgross@...e.com>
Subject: Re: [Xen-devel] [PATCH] xen/pci: try to reserve MCFG areas earlier

On 10/09/2019 18:48, Boris Ostrovsky wrote:
> On 9/10/19 5:46 AM, Igor Druzhinin wrote:
>> On 10/09/2019 02:47, Boris Ostrovsky wrote:
>>> On 9/9/19 5:48 PM, Igor Druzhinin wrote:
>>>> On 09/09/2019 20:19, Boris Ostrovsky wrote:
>>>>
>>>>> The other question I have is why you think it's worth keeping
>>>>> xen_mcfg_late() as a late initcall. How could MCFG info be updated
>>>>> between acpi_init() and late_initcalls being run? I'd think it can only
>>>>> happen when a new device is hotplugged.
>>>>>
>>>> It was a precaution against setup_mcfg_map() calls that might add new
>>>> areas that are not in MCFG table but for some reason have _CBA method.
>>>> It's obviously a "firmware is broken" scenario so I don't have strong
>>>> feelings to keep it here. Will prefer to remove in v2 if you want.
>>> Isn't setup_mcfg_map() called before the first xen_add_device() which is where you are calling xen_mcfg_late()?
>>>
>> setup_mcfg_map() calls are done in order of root bus discovery which
>> happens *after* the previous root bus has been enumerated. So the order
>> is: call setup_mcfg_map() for root bus 0, find that
>> pci_mmcfg_late_init() has finished MCFG area registration, perform PCI
>> enumeration of bus 0, call xen_add_device() for every device there, call
>> setup_mcfg_map() for root bus X, etc.
> 
> Ah, yes. Multiple busses.
> 
> If that's the case then why don't we need to call xen_mcfg_late() for
> the first device on each bus?
> 

Ideally, yes - we'd like to call it for every bus discovered. But boot
time buses are already in MCFG (otherwise system boot might not simply
work as Jan pointed out) so it's not strictly required. The only case is
a potential PCI bus hot-plug but I'm not sure it actually works in
practice and we certainly didn't support it before. It might be solved
theoretically by subscribing to acpi_bus_type that is available after
acpi_init().

Igor