linux-kernel - Re: [PATCH] m68k: disable SRAM at startup

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: <30445b83-50eb-40ae-a2db-43b98d0c3224@linux-m68k.org>
Date: Thu, 5 Sep 2024 17:52:33 +1000
From: Greg Ungerer <gerg@...ux-m68k.org>
To: Jean-Michel Hautbois <jeanmichel.hautbois@...eli.org>,
 Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: linux-m68k@...ts.linux-m68k.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] m68k: disable SRAM at startup

Hi JM,

On 5/9/24 00:26, Jean-Michel Hautbois wrote:
> Some of the internal SoC registers have a higher priority over the MMU
> virtual mappings. The SRAM bank is one of them. If the bootloader
> enables the internal SRAM at address 0x80000000, virtual memory access
> at this address will not hit the MMU - so no TLB data misses would
> occurr.
> 
> Since 0x80000000 is the virtual start address of all applications that
> bit of memory is getting stomped over with inconsistent code and data
> access.
> 
> Fix it by disabling the internal SRAM at startup.
> 
> Signed-off-by: Greg Ungerer <gerg@...ux-m68k.org>
> Tested-by: Jean-Michel Hautbois <jeanmichel.hautbois@...eli.org>
> Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@...eli.org>

I know this change fixed your specific problem, but it is not going
to work as a general solution.

For one not all ColdFire parts have an SRAM region and thus not all have
a valid %rambar register. Secondly some ColdFire parts (like the 5249)
have 2 SRAM regions, with mapping control registers named %rambar0
and %rambar1.

Some ColdFire uClinux applications use the mapped SRAM, so a blanket
disable is not the best idea in any case.

I am thinking it would be better to have a new Kconfig option that
allows disabling by the startup code for those ColdFire parts that
have SRAM (so appropriate "depends on"). That way it will only be
disable when that is what is needed. Maybe also have that configuration
allowing to configure and set the rambars so that a mapping
can be forced on if wanted.

Regards
Greg

> ---
>   arch/m68k/coldfire/head.S | 4 ++++
>   1 file changed, 4 insertions(+)
> 
> diff --git a/arch/m68k/coldfire/head.S b/arch/m68k/coldfire/head.S
> index c6d7fd28c6023..3901a49c47c89 100644
> --- a/arch/m68k/coldfire/head.S
> +++ b/arch/m68k/coldfire/head.S
> @@ -207,6 +207,10 @@ _start:
>   	movec	%d0,%CACR
>   	nop
>   
> +	movel   #0,%d0
> +	movec   %d0,%rambar
> +	nop
> +
>   #ifdef CONFIG_MMU
>   	/*
>   	 *	Identity mapping for the kernel region.
> 
> ---
> base-commit: 431c1646e1f86b949fa3685efc50b660a364c2b6
> change-id: 20240904-fix-cf-virt-mem-sram-abadb27fff2f
> 
> Best regards,