linux-kernel - Re: [PATCH 0/2] PCI: endpoint: BAR subrange mapping support

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]

Message-ID: <t3kgkqhg7ffenvrbyo6e6cdtxc7wfq5mpt2m5drvbdvesn7ow4@iobg4657himy>
Date: Tue, 6 Jan 2026 21:32:58 +0900
From: Koichiro Den <den@...inux.co.jp>
To: Niklas Cassel <cassel@...nel.org>
Cc: jingoohan1@...il.com, mani@...nel.org, lpieralisi@...nel.org, 
	kwilczynski@...nel.org, robh@...nel.org, bhelgaas@...gle.com, Frank.Li@....com, 
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] PCI: endpoint: BAR subrange mapping support

On Tue, Jan 06, 2026 at 10:30:40AM +0100, Niklas Cassel wrote:
> On Tue, Jan 06, 2026 at 10:52:54AM +0900, Koichiro Den wrote:
> > On Mon, Jan 05, 2026 at 05:55:30PM +0100, Niklas Cassel wrote:
> > > 
> > > You should also verify that the sum of all the sizes in the pci_epf_bar_submap
> > > array adds up to exactly pci_epf_bar->size.
> > 
> > I didn't think this was a requirement. I experimented with it just now, and
> > seems to me that no harm is caused even if the sum of the submap sizes is
> > less than the BAR size. Could you point me to any description of this
> > requirement in the databook if available?
> 
> 3.10.7 Inbound Features
> "Without address translation, your application address is passed from the
> TLPs directly through the application interface."
> 
> 
> Thus, when there is not an explicit translation, the DWC controller passes
> through a transaction untranslated.

I see your point now. Thanks for the clarification.

> 
> Sure, if there is no physical memory or IO registers at the physical address
> corresponding to the PCI address trying to be accessed, no harm done.
> 
> But because of the potential security implications, I think it is good to
> ensure that the whole PCI address range of the BAR has a physical mapping.

That makes sense. This (v1) series implicitly allows incremental iATU
programming via multiple dw_pcie_ep_set_bar() invocations with
incrementally added submaps, but if we want to prohibit any holes, it seems
reasonable to make the API contract stricter such that the caller must
prepare all sub-range mappings up front, and a one-shot API call should
either map the whole BAR or fail altogether (all-or-nothing).

Kind regards,
Koichiro

> 
> 
> Kind regards,
> Niklas