From: Gábor Lénárt (lgb_at_lgb.hu)
Date: 2005-04-22 08:17:53
On Thu, Apr 21, 2005 at 10:09:30PM -0500, Jim Brain wrote:
> It gets worse. The opcode in question could have updated an internal
> register:
>
> $67ff and #$10
>
> 67ff (and) gets pulled.
>
> $6800 is page fault, so force 0. Uh oh, as now .A is corrupt, and there
> is no way to reset it.
Yes, that's why I've assumed, that this kind of page protection would be
only useful to signal the OS to _terminate_ execution of the process but no
way to continue the execution of that process in any way, since we haven't
got reliable state of the CPU ... As I've already written, you may have
handler for segmentation fault signal eg in a modern UNIX system to handle
faults, you can't do this with my scheme of course. You can only say, that
process should be terminated because a fault is occured and we don't know
that what was the fault exactly, and where, and also registers may corrupt
etc ... My goal was only protect memory at least to be corrupted. Corruption
eg of a register of the CPU does not matter since we won't run the process
anymore. Of course it would be cool to be able to implement finer scheme,
but it's not possible without some suppor in the 6502 builtin.
> The only real way to do this is not allow such things to occur. Scan
> incoming code at page boundaries to insert BRK opcodes to handle such
> issues before you step into them. Or, ensure code that runs in your
> system does not create such issues.
That's not a secure system by definition I would like to create :) Which
cannot be crashed by - user space - software at all.
--
- Gábor
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.