| Re: [hatari-devel] Feature idea/question: primitive memory manager |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
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