linux-kernel - Re: [PATCH v3 3/3] PCI/sysfs: Prohibit unaligned access to I/O port on non-x86

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: <alpine.DEB.2.21.2601082358370.30566@angie.orcam.me.uk>
Date: Fri, 9 Jan 2026 00:38:05 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: David Laight <david.laight.linux@...il.com>
cc: Ziming Du <duziming2@...wei.com>, Bjorn Helgaas <bhelgaas@...gle.com>, 
    linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org, 
    liuyongqiang13@...wei.com
Subject: Re: [PATCH v3 3/3] PCI/sysfs: Prohibit unaligned access to I/O port
 on non-x86

On Thu, 8 Jan 2026, David Laight wrote:

> I'm not sure it makes any real sense for x86 either.

 FWIW I agree.

> IIRC io space is just like memory space, so a 16bit io access looks the
> same as two 8bit accesses to an 8bit device (some put the 'data fifo' on
> addresses 0 and 1 so the code could use 16bit io accesses to speed things up).

 Huh?  A 16-bit port I/O access will have the byte enables set accordingly 
on PCI and the target device's data lines are driven accordingly in the 
data cycle.  Just as with MMIO; it's just a different bus command (or TLP 
type for PCIe).

 There's no data FIFO or anything as exotic in normal hardware to drive or 
collect data for port I/O accesses wider than 8 bits.  Some peripheral 
hardware may ignore byte enables though to simplify logic and e.g. assume 
that all port I/O or MMIO accesses are of a certain width, such as 16-bit 
or 32-bit.

> The same will have applied to misaligned accesses.

 Misaligned accesses may or may not have to be split depending on whether 
they span the data bus width boundary or not.  E.g. a 16-bit access to 
port I/O location 1 won't be split on 32-bit PCI as it fits on the bus: 
byte enables #1 and #2 will be driven active and byte enables #0 and #3 
will be left inactive.  Conversely such an access to location 3 needs to 
be split into two cycles, with byte enables #3 and #0 only driven active 
respectively in the first and the second cycle.

 The x86 BIU will do the split automatically for port I/O instructions as 
will some other CPU architectures that use memory access instructions to 
reach the PCI port I/O decoding window in their memory address space (this 
is a simplified view, as the split may have to be done in the chipset when 
passing the boundary between data buses of a different width each).

 With other architectures such as MIPS designated instructions need to be 
used to drive the byte enables by hand for individual partial accesses in 
a split access, and the remaining architectures cannot drive some of the 
byte-enable patterns needed for such split accesses at all (and do masking 
in software instead for unaligned accesses to regular memory).

> But, in reality, all device registers are aligned.

 True, sometimes beyond their width too.

  Maciej