Protecting RISC OS

Is it too much of an onerous task to provide some means of preventing applications from crashing the OS? When testing apps on the Beagleboard some form of protection would be useful to avoid constantly having to re-boot the machine. Would the OS have to re-written from srcatch for this to be possible?

To get the level of protecting that BSD, Linux, modern versions of Windows, etc. provide, we probably would have to rewrite a fair amount of the OS (or at least break compatability with a lot of existing programs). But there are some significant things which we can do without breaking existing (well-behaved) programs:

• Get rid of as much as possible of the ‘zero page’ area from &0 to &8000. This will cause null pointer issues to be caught sooner, and without the risk of trashing the processor vectors. It’ll also catch software that tries to poke known addresses within kernel memory instead of going via the proper APIs.
• Increase the level of protection given to the contents of the RMA. However this will be tricky due to the lack of protection which the RMA currently has, so it will have to be some kind of ‘opt-in’ system for new modules only.
• Increase the level of protection given to other areas of memory. When you create a dynamic area there’s a flag you can set to say that the area should be accessible by just the current Wimp task. However I don’t think that flag does anything yet. Plus on ARMv7 you can mark pages as non-executable, which would be useful for things like screen memory, IO buffers, etc.
• Make the ROM modules more vigilant with their parameter verification, add checksums/guard words to important data structures, etc.
• Make the kernel/wimp more aware of what’s going on. In Select/Adjust ROL added stack markers to help detect background errors and other issues. We could do a similar thing with RO 5, so that the kernel can more reliably work out which program/module is at fault, what corrective actions may be required (e.g. disabling a crashing IRQ handler), etc.
• Make the OS write out crash dumps when things go wrong. Although this won’t directly protect the OS, if a system is in place where the crash dumps can be uploaded to the ROOL site for analysis, etc. then it could easily help us track down and fix bugs.
• Develop a set of tools which can be used to test the OS and programs – making sure that things behave properly when running out of memory, when SWIs return errors, when modules get reinitialised during use, etc.
• Come up with some kind of system where SWIs can check the stack limit. Maybe the SWI dispatcher can check that a certain per-module minimum amount of space is available, and then if any individual SWI needs more than that then they can call a new stack check SWI. A similar system could be used for IRQ handlers (and for SWIs called by IRQ handlers).
• Get fixing bugs! E.g. I remembered recently that I still haven’t checked in a fix to stop Escape from being used to cancel USB transfers, the Kernel can get stuck in an infinite loop in CheckForNullAllocn if the heap gets corrupted in a certain way, it would be good to integrate Absolutely with the OS to fix the stupid “no writeable memory at this address” when loading large programs, fix the FileCore RAM disc crash, all the bugs in the bug tracker, etc.

Get fixing bugs!

• The VDU PreGrow handler temporarily leaving some pointers pointing to bad memory, resulting in infinite abort loops if something tries VDU output while screen memory is being resized/moved
• Make the PreReset sequence nicer/fix the USB drivers to not enable IRQs/callbacks
• Fix some of the horrible stack unwinding the SharedCLibrary does (ISTR that in Select/Adjust they’ve actually removed the event handler support from CLib)

Any more people can think of? ;-)

Wow! a mind field :(

Thank you for taking the time to explain some of the many problems.