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.