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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200117160502.GA92383@google.com>
Date:   Fri, 17 Jan 2020 10:05:02 -0600
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Nicholas Johnson <nicholas.johnson-opensource@...look.com.au>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>, linux-acpi@...r.kernel.org
Subject: Re: [[RFC PATCH v1] 1/1] PCI: Add pci=nobbn to ignore ACPI _BBN
 method to override host bridge bus window

[+cc Rafael, linux-acpi, start of thread at
https://lore.kernel.org/lkml/PSXP216MB0438F3D8C09957C6A45BC43D80580@PSXP216MB0438.KORP216.PROD.OUTLOOK.COM/T/#u]

On Fri, Jan 17, 2020 at 03:00:11PM +0000, Nicholas Johnson wrote:
> On Thu, Jan 16, 2020 at 11:13:13PM +0100, Thomas Gleixner wrote:
> > Nicholas Johnson <nicholas.johnson-opensource@...look.com.au> writes:
> > 
> > > Add pci=nobbn kernel parameter.
> > >
> > > Override the host bridge bus resource to [bus 00-ff] when specified.
> > 
> > Fine, but you completely fail to explain why this is useful and why
> > someone would utilize this command line parameter.
>
> There are motherboards with single PCIe root complex which give 
> significantly less than [bus 00-ff] via CRS. I own one with [bus 00-7f] 
> and have seen some with significantly less.
> 
> A user who wants to use more busses than the motherboard advertises will 
> want to use this kernel parameter, for instance if they have a lot of 
> PCIe switches or Thunderbolt 3 devices.

I don't think this is a good idea.  "pci=nocrs" was mainly useful to
work around Linux defects in handling _CRS methods.  I don't think we
have comparable defects in our handling of _BBN.

In your example, the BIOS is telling us the bridge leads to [bus
00-7f].  We don't know what is at [bus 80-ff].  Maybe that range is
valid and usable, and maybe it's not.  It could be routed to a
different host bridge, it could contain devices the BIOS uses for its
own purposes, it could be completely invalid.

If we *did* decide this is a good idea, "nobbn" is a misleading name.
_BBN evaluates to a single bus number, not a range.  In your example,
BIOS is supplying _BBN=0 and _CRS that contains [bus 00-7f].  "nobbn"
suggests that'd we'd ignore _BBN.  But this patch actually ignores the
bus number range from _CRS, so it has nothing to do with _BBN.

> This is similar to how we have pci=nocrs to override motherboards with 
> issues. The bus resource is not overridden by pci=nocrs, even though it 
> will usually come from the same method. However, I believe it would be 
> unwise to change pci=nocrs to include bus resource, as detailed in my 
> original RFC.

For reference, I think this original RFC was
https://lore.kernel.org/r/PSXP216MB04385B2C1BB518E5219C30CE80580@PSXP216MB0438.KORP216.PROD.OUTLOOK.COM

Bjorn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ