On Wed, 3 Jan 2024 at 22:12, Eero Tamminen <oak@xxxxxxxxxxxxxx
<mailto: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 <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 <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/ <https://lwn.net/Articles/885220/>
- Eero
--
http://mikro.atari.org <http://mikro.atari.org>