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:   Fri, 24 Sep 2021 13:12:31 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
To:     Andrew Gabbasov <andrew_gabbasov@...tor.com>,
        linux-renesas-soc@...r.kernel.org, linux-kernel@...r.kernel.org,
        Sergei Shtylyov <sergei.shtylyov@...il.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>
Subject: Re: [PATCH] memory: renesas-rpc-if: Avoid unaligned bus access for
 HyperFlash

On 22/09/2021 20:48, Andrew Gabbasov wrote:
> HyperFlash devices in Renesas SoCs use 2-bytes addressing, according
> to HW manual paragraph 62.3.3 (which officially describes Serial Flash
> access, but seems to be applicable to HyperFlash too). And 1-byte bus
> read operations to 2-bytes unaligned addresses in external address space
> read mode work incorrectly (returns the other byte from the same word).
> 
> Function memcpy_fromio(), used by the driver to read data from the bus,
> in ARM64 architecture (to which Renesas cores belong) uses 8-bytes
> bus accesses for appropriate aligned addresses, and 1-bytes accesses
> for other addresses. This results in incorrect data read from HyperFlash
> in unaligned cases.
> 
> This issue can be reproduced using something like the following commands
> (where mtd1 is a parition on Hyperflash storage, defined properly
> in a device tree):
> 
> [Correct fragment, read from Hyperflash]
> 
>     root@...r-gen3:~# dd if=/dev/mtd1 of=/tmp/zz bs=32 count=1
>     1+0 records in
>     1+0 records out
>     root@...r-gen3:~# hexdump -C /tmp/zz
>     00000000  f4 03 00 aa f5 03 01 aa  f6 03 02 aa f7 03 03 aa  |................|
>     00000010  00 00 80 d2 40 20 18 d5  00 06 81 d2 a0 18 a6 f2  |....@ ..........|
>     00000020
> 
> [Incorrect read of the same fragment: see the difference at offsets 8-11]
> 
>     root@...r-gen3:~# dd if=/dev/mtd1 of=/tmp/zz bs=12 count=1
>     1+0 records in
>     1+0 records out
>     root@...r-gen3:~# hexdump -C /tmp/zz
>     00000000  f4 03 00 aa f5 03 01 aa  03 03 aa aa              |............|
>     0000000c
> 
> Fix this issue by creating a local replacement of the copying function,
> that performs only properly aligned bus accesses, and is used for reading
> from HyperFlash.
> 
> Fixes: ca7d8b980b67f ("memory: add Renesas RPC-IF driver")
> Signed-off-by: Andrew Gabbasov <andrew_gabbasov@...tor.com>
> ---
>  drivers/memory/renesas-rpc-if.c | 47 ++++++++++++++++++++++++++++++++-
>  1 file changed, 46 insertions(+), 1 deletion(-)
> 

Thanks for the patch.

Please rebase and test on a recent Linux kernel. This looks like work on
something slightly older or stable kernel, since you Cc not the address
from maintainers.

The patch came slightly after Wolfram's and I wonder whether you hit
similar issue:
https://lore.kernel.org/lkml/20210922091007.5516-1-wsa+renesas@sang-engineering.com/


Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ