linux-kernel - Re: RFC: arch: shall we have generic readl_be()/writel_be()/... or in_be32()/out

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] [day] [month] [year] [list]

Date:   Fri, 11 Dec 2020 13:20:09 +0000 (GMT)
From:   "Maciej W. Rozycki" <macro@...ux-mips.org>
To:     Alan Stern <stern@...land.harvard.edu>
cc:     "Enrico Weigelt, metux IT consult" <info@...ux.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-arch@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: RFC: arch: shall we have generic readl_be()/writel_be()/... or
 in_be32()/out_be32() ?

On Wed, 9 Dec 2020, Alan Stern wrote:

> > I believe we should have generic functions, that all archs implement
> > (possibly doing automatic conversion, if necessary), which are used
> > by everybody else.
> > 
> > What's your oppionion on that ?
> 
> It certainly seems reasonable.  Another possibility, less stringent, is 
> to require that definitions exist on all architectures that can have 
> big-endian MMIO (or port-based IO).  For example, any architecture 
> which might select CONFIG_EHCI_BIG_ENDIAN_MMIO, as used in ehci.h.

 Lane swapping is a complex matter where there is an endianness mismatch 
between buses.  A bus bridge may implement the byte lane match policy or 
the bit lane match policy, or even both to choose from, perhaps on a 
case-by-case basis for individual accesses (e.g. with a pair of address 
windows decoded to the other bus according to a different policy each; I 
actually have such a system).

 Consequently not only data transferred may have to be transformed, but so 
may have the address used.  Also the transformation will be different 
depending on whether data accessed is to be interpreted numerically (where 
the bit lane match policy is more suitable) such as with CSR access, or as 
a byte stream (where the byte lane match policy is) such as with PIO data 
moves.

 See arch/mips/include/asm/io.h and arch/mips/include/asm/*/mangle-port.h 
for an example where we take care of different cases.

 Building infrastructure for doing this all in a generic manner would I 
think be a good idea, but then a major effort as well, and you'd have to 
coordinate it with all the arch maintainers.

  Maciej