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

Message-ID: <cc318d16-941c-49e5-b54a-1c52c5f47011@yoseli.org>
Date: Thu, 5 Sep 2024 16:03:03 +0200
From: Jean-Michel Hautbois <jeanmichel.hautbois@...eli.org>
To: Greg Ungerer <gerg@...ux-m68k.org>, philippe.demuyter@...q.eu
Cc: linux-m68k@...ts.linux-m68k.org, linux-kernel@...r.kernel.org,
 Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [PATCH] m68k: disable SRAM at startup

Hi Greg,

On 05/09/2024 09:52, Greg Ungerer wrote:
> 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.

Thanks for this clarification. TBH, I sent the mail and thought about it 
after :-(.
The patch is in my branch, and solves the issues in [1], so I decided to 
send it.
*But* I should have asked first your approval as you are the one who 
found it and mark it as RFC probably. I'm sorry for that...

[1]: 
https://lore.kernel.org/linux-m68k/mvmed8dlewg.fsf@linux-m68k.org/T/#m0e4c8f0b9df0a03f3d0b5cf2246661d0bb3a370b

> 
> 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.

Interesting.
I will keep this patch for my own case for now, as it does not apply and 
wait for this Kconfig option to make it clean !

JM