linux-kernel - Re: [PATCH] PCI: Avoid handing out address 0 to devices

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:   Thu, 14 Apr 2022 12:07:43 -0500
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>
Cc:     Bjorn Helgaas <bhelgaas@...gle.com>, linux-pci@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] PCI: Avoid handing out address 0 to devices

On Thu, Apr 14, 2022 at 02:10:43AM +0100, Maciej W. Rozycki wrote:
> On Wed, 13 Apr 2022, Bjorn Helgaas wrote:
> 
> > > Address 0 is treated specially however in many places, for example in 
> > > `pci_iomap_range' and `pci_iomap_wc_range' we require that the start 
> > > address is non-zero, and even if we let such an address through, then 
> > > individual device drivers could reject a request to handle a device at 
> > > such an address, such as in `uart_configure_port'.  Consequently given
> > > devices configured as shown above only one is actually usable:
> > 
> > pci_iomap_range() tests the resource start, i.e., the CPU address.  I
> > guess the implication is that on RISC-V, the CPU-side port address is
> > the same as the PCI bus port address?
> 
>  Umm, for all systems I came across except x86, which have native port I/O 
> access machine instructions, a port I/O resource records PCI bus addresses 
> of the device rather than its CPU addresses, which encode the location of 
> an MMIO window the PCI port I/O space is accessed through.

My point is only that it is not necessary for the PCI bus address and
the struct resource address, i.e., the argument to inb(), to be the
same.

I tried to find the RISC-V definition of inb(), but it's obfuscated
too much to be easily discoverable.

Bjorn