linux-kernel - Re: [PATCH] ARM: dts: STi: stih407-family: Disable reserved-memory co-processor nodes

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, 17 Jun 2016 11:56:54 +0200
From:	Maxime Coquelin <maxime.coquelin@...com>
To:	Lee Jones <lee.jones@...aro.org>,
	<linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>, <arnd@...db.de>,
	Olof Johansson <olof@...om.net>
CC:	<kernel@...inux.com>, <patrice.chotard@...com>
Subject: Re: [PATCH] ARM: dts: STi: stih407-family: Disable reserved-memory
 co-processor nodes

On 06/07/2016 10:37 AM, Lee Jones wrote:
> This patch fixes a non-booting issue in Mainline.
>
> When booting with a compressed kernel, we need to be careful how we
> populate memory close to DDR start.  AUTO_ZRELADDR is enabled by default
> in multi-arch enabled configurations, which place some restrictions on
> where the kernel is placed and where it will be uncompressed to on boot.
>
> AUTO_ZRELADDR takes the decompressor code's start address and masks out
> the bottom 28 bits to obtain an address to uncompress the kernel to
> (thus a load address of 0x42000000 means that the kernel will be
> uncompressed to 0x40000000 i.e. DDR START on this platform).
>
> Even changing the load address to after the co-processor's shared memory
> won't render a booting platform, since the AUTO_ZRELADDR algorithm still
> ensures the kernel is uncompressed into memory shared with the first
> co-processor (0x40000000).
>
> Another option would be to move loading to 0x4A000000, since this will
> mean the decompressor will decompress the kernel to 0x48000000. However,
> this would mean a large chunk (0x44000000 => 0x48000000 (64MB)) of
> memory would essentially be wasted for no good reason.
>
> Until we can work with ST to find a suitable memory location to
> relocate co-processor shared memory, let's disable the shared memory
> nodes.  This will ensure a working platform in the mean time.
>
> NB: The more observant of you will notice that we're leaving the DMU
> shared memory node enabled; this is because a) it is the only one in
> active use at the time of this writing and b) it is not affected by
> the current default behaviour which is causing issues.
>
> Fixes: fe135c6 (ARM: dts: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory)
> Signed-off-by: Lee Jones <lee.jones@...aro.org>
> ---
>   arch/arm/boot/dts/stih407-family.dtsi | 3 +++
>   1 file changed, 3 insertions(+)
>
>

That sounds reasonable:
Acked-by: Maxime Coquelin <maxime.coquelin@...com>

Arnd, Olof, can you pick this patch directly in -rc fixes,
as it prevents STi boards to boot correctly?

Thanks in advance,
Maxime