Re: [hatari-devel] Feature idea/question: primitive memory manager

Just to follow-up on this thread...

... while reading https://tbl.nu/2019/08/20/Tooling/ one couldn't but notice how much stuff in that article has been already done in Hatari for ages. However when it comes to memory protection, they took a different path: they let the m68k application request / clear the protection status. Therefore all of the mentioned issues in this thread would be solved because it would be me who say "ok, this area is only meant to be read" (e.g. for text segment), this segment is for writes only (video ram) etc.

Not perfect but could help in many scenarios. The natfeats API is the perfect candidate for it.

On Wed, 3 Jan 2024 at 22:12, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:

Hi,

On 2.1.2024 11.52, Miro Kropáček wrote:
> I have been thinking yet of another improvement, text segment could be
> marked as r/o and that code flow could be restricted only to given
> program's text segment (yes, this means no plugins and external functions
> via e.g. cookie jar)

Sounds like a good idea (to easily catch a subset of the issues)!

> but then again, this wont solve the main issue I was
> hoping to solve, e.g. wrong access to arrays

IMHO the very best solution for that would be compiler instrumentation
i.e. porting GCC ASAN support to m68k. On linux its performance is very
reasonable, so it might be feasible on Atari from perf point too.

(These kind of checkers on PC use canaries, they do not check everything.)

Another option is using a (replacement) allocator that has either build
or run-time options for heap consistency checks, like Glibc does:
https://www.gnu.org/software/libc/manual/html_node/Heap-Consistency-Checking.html

On Linux, AFAIK best heap alloc checker lib is DUMA, but it's memory
usage overhead is huge and I'm not sure it could be ported with
reasonable effort, as it adds MMU protected guard pages on each allocation:
https://github.com/johnsonjh/duma

They catch less issues than ASAN, but can still be very useful.

> stack overflow etc.

Maybe Hatari CPU core could (optionally) check that the return value
pushed to stack is not overwritten before the actual return...

Nicolas & Toni, any comments on that?

Note: e.g. both EmuTOS and m68k Linux modify the return value in the
stack, to jump somewhere else on RTS, but they do it only from a
specific place (which means that it can be special cased, like is
already done in Hatari profiler).

=> My suggestion would be for an option enabling such check taking an OS
address, on which such return address modification would be ignored.

Note: this feature would be most useful when such return does not cause
any (immediate) exceptions. If they do cause exceptions, return address
location is likely to be easy to catch with Hatari profiler (when
program include debug symbols), and with more effort using CPU history
and/or exec trace.

Btw. Due to security impact of stack based attacks, Linux kernel has
also options for stack validation with HW support on some platforms:
https://lwn.net/Articles/885220/

- Eero