linux-kernel - Re: [PATCH v1] Intel Sky Lake-E host root ports check.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <026bf48f-caf1-2d1e-b4de-553a6625a51b@deltatee.com>
Date:   Mon, 21 Mar 2022 10:30:19 -0600
From:   Logan Gunthorpe <logang@...tatee.com>
To:     Shlomo Pongratz <shlomopongratz@...il.com>
Cc:     linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
        andrew.maier@...eticom.com, bhelgaas@...gle.com,
        Shlomo Pongratz <shlomop@...ops.com>
Subject: Re: [PATCH v1] Intel Sky Lake-E host root ports check.



On 2022-03-21 10:21, Shlomo Pongratz wrote:
> See inline
> 
> Shlomo.
> 
>> On 21 Mar 2022, at 17:46, Logan Gunthorpe <logang@...tatee.com
>> <mailto:logang@...tatee.com>> wrote:
>>
>>
>>
>> On 2022-03-21 08:31, Shlomo Pongratz wrote:
>>> On commit 7b94b53db34f ("PCI/P2PDMA: Add Intel Sky Lake-E Root Ports
>>> B, C, D to the whitelist")
>>> Andrew Maier added the Sky Lake-E additional devices
>>> 2031, 2032 and 2033 root ports to the already existing 2030 device.
>>> Note that the Intel devices 2030, 2031, 2032 and 2033 are ports A, B,
>>> C and D.
>>> Consider on a bus X only port C is connected downstream so in the PCI
>>> scan only
>>> device 8086:2032 on 0000:X:02.0 will be found as bridges that have no
>>> children are ignored.
>>> As a result the routine pci_host_bridge_dev will return NULL for
>>> devices under slot C.
>>> In the proposed patch port field is added to the whitelist which is 0
>>> for 2030, 1 for 2031,
>>> 2 for 2032 3 for 2033 and 0 for all other devices.
>>
>> The patch looks largely ok, but I'm not sure I follow this description.
>>
>> It sounds like in practice the host bridges B, C and D are not addressed
>> at function 0 as was assumed. But what does it mean that only C is
>> connected downstream? How can a bridge not be connected downstream?
>>
> Maybe it is wrong usage of words.
> I mean three are no devices behind port A and B, it is possible if there
> if one has empty PCI slots.
> I my case I had only on NVMe SSD connected to port C.

If a bridge has no devices behind it, it's not ever going to get into
the p2pdma code; so I'm not sure how that's relevant. And just because
one user doesn't have any device behind a bridge, doesn't mean that all
users have no devices under that bridge.

Sounds like the commit description and comments just neeed to change to
note that the function of each of the bridge is not always zero, as
originally assumed.

Logan