Broken Translation Lookaside Buffer

A security bug, as if anyone cares about such things…

RPCEmu caches the result of MMU translations, but that is done without regard for processor mode. This results in user mode code being able to access memory it should not be able to access.

If one is running a secure operating system under RPCEmu this a large security hole, this would also effect a sandbox program running under RISC OS but I suspect such a program does not exist.

It also breaks the Aborttrap tests in the RISC OS Source.

RPCEmu caches the result of MMU translations, but that is done without regard for processor mode. This results in user mode code being able to access memory it should not be able to access.

This is known issue for a considerable time, there is work on this to fix it, but no timescales as to when it’ll be done.

If one is running a secure operating system under RPCEmu this a large security hole.

Luckily we are just running RISC OS, so this is no-less secure than its regular operation.

It also breaks the Aborttrap tests in the RISC OS Source.

I’ve not heard of this test, could you give me some more information/source?

The tests are these BASIC programs:

https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/-/tree/master/Dev/AbortTrap

attest_ap and attest_da are the ones that fail on RPCEmu. It’s the same test code, but via different APIs. They check that OS_AbortTrap (and abortable DAs) are implemented correctly for all the different page protection levels/settings, both for accesses that are fully within a page, and ones that cross to/from unmapped memory. To check that the OS calls AbortTrap correctly, the data which the AbortTrap handler interacts with is different to the contents of the test page. But this means they’re also capable of catching some cases where the hardware/emulator isn’t triggering aborts correctly.

RPCEmu caches the result of MMU translations, but that is done without regard for processor mode. This results in user mode code being able to access memory it should not be able to access.

Is that what it’s doing…caching the result? I assumed it was ignoring the security bits in the MMU entries when I initially reported it to Peter.

Does that mean a potential workaround is to flush the TLB at every Access Abort as I vaguely recall seeing one abort after a change to the TLB and then no more. I might give that a try.

I’m sure Peter can correct me, but I do recall when I raised it again at one of the London shows, it need some major changes to correct, but was low on the list as RO5 doesn’t require it.

All of the current emulators have one issue or other when it comes to RO machine emulation, so we’re stuck with testing on physical unfortunately. RedSquirrel is probably the closest for accurate ARMv4 emulation, although still requires a “last pass” test on physical to ensure there’s no cache invalidation issues. RO5 doesn’t run under it following a change (POST I think) many years ago; I created a hack to get it working at the time, but a subsequent change has broken something else, so RO5 doesn’t POST.

If one is running a secure operating system under RPCEmu this a large security hole.

I took this to refer to the underlying OS, for example, Windows, MacOS or Linux. If that is right, the reference to RISC OS’s intrinsic insecurity is neither here nor there: what is happening is that an otherwise secure system is being compromised by a RISC OS insecurity.

I take it to refer to a potential vulnerability if someone is using said secure OS under the emulator.

If an issue in an emulated RISC OS can punch a hole in the host, I’m afraid the finger must point firmly at the host, not RISC OS.

It’s the job of the OS to keep itself secure in the face of application misdemeanours, not the other way around.
But, shhh, don’t tell RISC OS that. ;)

I took this to refer to the underlying OS, for example, Windows, MacOS or Linux.

You would be wrong.

You would be wrong.

Well, it wouldn’t be the first time…