No more big 32-bit cores for RISC OS from 2022

any idea of how we could prevent this without major rewriting of the OS itself?

Ah, now, remember when I pointed out that the system will happily give anything supervisor access?
https://heyrick.eu/blog/index.php?diary=20160803

I am thinking of some separate situations:

Malware
Can patch the ROM on the fly to avoid being detected by antivirus. The ROM is no longer a real ROM. Once it’s loaded signature is checked, if the malware doesn’t store it back the image on FAT32 is still correctly signed now potential checksums are changed. Hard to catch, any idea of how we could prevent this without major rewriting of the OS itself?

Signed apps? The methods of running check the signature matches a list. If the malware can’t run it isn’t going be infecting anything

Good software
May want to patch the ROM to improve features. How do we deal with this? No more possible?

Patch testing on the open OS, integrated @ROOL into secure. As you say, no longer possible on the secure.

ROM Modules replacements
For instance how do we consider SharedCLibrary RAM when it replaces ShareCLibrary ROM?

SharedC in ROM should always be the most up to date revision. IIRC the OS shifts into RAM in the HAL sequence so you’re back to the “prevent malware running” in secure there.
Other interesting ideas (Nemo would have half a dozen universe of them) will all need to be developed and tested on the non-secure.

Special RISC OS Distributions
like RComp RISC OS for their own hardware?

Now that’s an interesting question. To be a secure release it would need to signed by ROOL and be in a state other than beta test. iMx6 fails that one.¹
I’d suggest that the vendor would need to discuss with ROOL the method for getting a non-beta build that might not be open availability i.e. not appear on the ROOL downloads.

Of course if there’s nothing proprietary in the ROM they might not care about that hiding.

It does mean that vendors need to work with the laid down procedures to be able to use a marked stable/secure release. It’s also an extra incentive to tick all the boxes to get it listed as non-beta.
Would you want to buy an item that had a beta, non-secure, OS when a very similar item had a fully certified, stable, secure version?

Final item we have Rick, stating where the elephant is

Ah, now, remember when I pointed out that the system will happily give anything supervisor access?

Yes, oh hacker in chief and head of security testing. :)
I do recall.

So, why would anyone sign an app with that in?

¹ Edit It occurs to me that more so than iMx6 the ARMBook² is not even a listed beta in the ROOL pages.

² Nice name. I may misremember but I think I did a © in my original comment.

IIRC the OS shifts into RAM in the HAL sequence

According to the HAL Boot as traced by Chris Mahoney it’s in RAM by the end of the HAL code so everything the kernel does is in the RAM copy.

The HAL zero’d the RAM so that should be clean at this point, refuse to let anything unsigned run and the OS environment should stay clean (famous last words)

How compatible is the general concept of RISC OS modules with modern security? Applications being free to unplug OS modules and plug in custom versions is obviously a non starter, but is the general concept valid? Or should modules just be a way of structuring the OS, with the more widely used modules becoming an integral part (not necessarily active by default), and the obscure ones being ditched?

If you containerised the OS so each task had a separate instance or our current single context OS, they could replace any modules they liked and not affect anything else.

But I think we are running before we can even crawl here.

So, why would anyone sign an app with that in?

Anything that talks to hardware in any way may well need to pop into SVC mode in order to do it.

Given that signed apps is unlikely to happen any time soon (I’d rather non-signed apps and better use of the available hardware first), I will suggest two methods that could bypass the entire process.

First, the use of a helper module. If the code to fiddle with internal stuff was hidden in a helper module, then it could be used by code hidden in the app to do nefarious stuff. Given that numerous module entry points are entered in a privileged mode, it doesn’t even need to be complicated. Indeed, just the ability to read and write words could be enough when used correctly. Like, say, a routine to load or save an index from disc could instead poke memory if the file handle is something specific like -123 and the pointer to workspace is actually the address to fiddle with. May or may not ever get spotted.
May well also defeat containerising because in order to trap this, every memory access would need to be trapped, and given how the OS API scatters blocks of memory all over the place (thus making it a lot more difficult than simply marking accesses outside of app workspace as out of bounds) one might decide that it’s just too damn slow.

The second method is a two stage process. Generally speaking, ARM machines boot by loading some sort of bootloader, which in turn loads the kernel, usually under some sort of scripted control, like uEnv.txt or CONFIG.TXT. So simply place a small bit of code in there and modify the boot to load that bit of code, which patches bits of the OS, which defeats the app signing process, and then kick-starts loading the kernel.
It’s a much more complex process (you’re basically running on bare metal) and prone to failure (either you attack known ‘stable’ releases, or use some sort of pattern matching to locate the desired code), not to mention having to work out how to find and load the kernel image into the correct place manually… but it is possible.
Of course, one could try to write protect certain things, but without filtering and vetting a lot of stuff, it may be possible to undo that, either via the API or at a disc sector level by fiddling with the directory data.

In short, I’ll repeat what I’ve said already. The RISC OS API was written in a day when single users made use of the machines, and connectivity to other systems meant Econet ¹, so while it is possible to think of ways to make the system a little more resiliant to casual hacking, it is not possible given the current API to make it “secure”. I can envision that the only way to do that is a complete fully sandboxed emulation on a per-app basis, but this will create its own problems – not just the big speed hit, but also issues with intentional data transfer such as drag-saves.

RISC OS is a product of a more innocent time.
It shows.

¹ It is perhaps worth pointing out the astonishing lack of anything even remotely resembling security in a networking protocol intended for educational use where passwords were sent entirely in the clear (not even hashed ²), and then there’s the Peek, Poke, RemoteJSR, RemoteProcedure, and InsertKeypress stuff ³. While later restricted to certain privileged stations, it was not a hardship to fiddle links on the board to shift the station number into range to have fun in a classroom.

² Only needs three bytes for simple hashing. A length byte, and a 16 bit CRC. If one takes the user’s password and merges it with their user name in some way (like EORing it), then starts a CRC on the result, using the initial value that is the first character of the username, to derive a 16 bit CRC and a “length of password”, one should arrive at two values (three bytes) that will represent the password in a way that is not only impossible to yank directly from the wire, but would also mean that the values are different for multiple users with identical passwords. In order to determine what a user’s password is, you’d need to run a dictionary attack on them one by one.

³ http://beebwiki.mdfs.net/Immediate_operations

First, the use of a helper module.

Unsigned. Next.

The second method is a two stage process. Generally speaking, ARM machines boot by loading some sort of bootloader, which in turn loads the kernel, usually under some sort of scripted control, like uEnv.txt or CONFIG.TXT.

That’s valid, but then having said

So simply place a small bit of code in there and modify the boot to load that bit of code, which patches bits of the OS, which defeats the app signing process,

you go on to say

It’s a much more complex process (you’re basically running on bare metal) and prone to failure (either you attack known ‘stable’ releases, or use some sort of pattern matching to locate the desired code), not to mention having to work out how to find and load the kernel image into the correct place manually… but it is possible.

So, it is possible but the effort required is much increased, and possibly requires doing again after every new ROM release.
Thus, we have an improvement. Of course, it would be difficult to make things easier to hack.

For your second scenario I suppose you’d be looking for a secure (or more secure than current) bootloader.
I’d be inclined to leave that element until after the work as outlined earlier.

Unsigned. Next.

In some alternate reality where a malware writer isn’t able to get something unpleasant signed at least once.
Remember, automatic scanning has limitations, and there’s little way that anybody is going to be able to do it manually (and that still has limitations).

Not to mention, it is rather likely that the enforcement of loading signed apps will be optional for a whole, mostly due to the utter chaos that it will cause as everything breaks, not to mention some stuff that works right now may never be further updated (and hence signed). Perhaps it can be added after the fact, but we’re running into the perpetual “who will do it” question.

Remember when I used to advocate for having the zero page be more than the ZeroPain module or faulting, saying that there ought to be at least something fake at that location for software that inadvertantly (albeit incorrectly) accesses &0 or thereabouts? Reality ensues.

As it will here.

So, it is possible but the effort required is much increased,

That depends on the platform. It may be “difficult” on the Pi as the boot process is an opaque binary blob.
It would be much simpler on an OMAP platform, as the boot is handled by U-Boot, which is open source, so one could theoretically copy-paste bits of code straight out of that in order to find the ROM image, load it, mess with it, and then run it.

and possibly requires doing again after every new ROM release.

This depends on whether the system will use hardcoded offsets that will only work on known (likely stable) releases, or whether it will use heuristics to scan the ROM for certain code sequences.
This may be complicated by two things – firstly, the compiler (this will be written in C, right?) doesn’t always generate identical code, and secondly the ROM may be compressed and itself subject to some sort of checksum/CRC. Again, not impossible to defeat, especially if you can jump in between system startup and RISC OS startup.

On the face of it, I am not really convinced that signing stuff is really worth the effort when there are so many other things that need attention first (we’re single core, we barely touch the hardware FP, we pretty much don’t make use of the GPU facilities so can’t play HD video on a lowly Pi or Beagle, we don’t do IPv6, nor WiFi, nor Bluetooth, and our support for non-Western European languages is…lacking) much of which might be expected by people who might want to use the platform as their primary.

As such, while it’s amusing to talk about ways to hijack system startup, the reality is that nobody is going to be interested. One might be able to lift the bank account details of the few clueless people that think the platform is “safe” due to its obscurity, but then again some basic social engineering and no hacking at all might get better results for less effort.

Of course, it would be difficult to make things easier to hack.

True, true. ;-)

I’d be inclined to leave that element until after the work as outlined earlier.

I’d be inclined to leave all of this until after work to better use the facilities already available to the OS.

Reality ensues…

Coo, infinite link text, how did you manage that?

BTW. Busy watching what I listened to earlier today: LH = WDC x 7

@ Druck

If you containerised the OS so each task had a separate instance or our current single context OS, they could replace any modules they liked and not affect anything else.

Could you please explain which type of containerisation are you envisioning?

• Docker-like?
  • So having a new RISC OS Kernel (rewritten from scratch, multi-core etc…) that runs in EL2 and supports guest RISC OS systems where the guest offers an API compatible with Classic RISC OS Kernel to the Application?
  • If so how are we going to reconcile the various Apps on the WIMP? Rewriting the WIMP to finally be what it should have been and remove all the pieces that should belong to the kernel?

• FreeBSD jails like?
  • That doesn’t seems to be what you imply, but for completeness I mention it, in this case we need to add support for containerisation to the existing Kernel, any idea how this could be achieved?

• SystemD containers like?

• Do you mean something more similar to an Hypervisor approach?
  • Running something like Genode in EL1 and then run multiple instances of Classic RISC OS on top of it? If so, again, how do you envision the “reconciliation” of multiple apps on a single WIMP?

Just curious and lots of interesting ideas also above!

@ Steve Pampling

Signed apps? The methods of running check the signature matches a list. If the malware can’t run it isn’t going be infecting anything

So are you suggesting ROOL to sign every existing Application as well?

SharedC in ROM should always be the most up to date revision. IIRC the OS shifts into RAM in the HAL sequence so you’re back to the “prevent malware running” in secure there.

But in reality it is not. each new version of DDE comes (quite often) with a new version of ShareClibrary. But if it’s signed then the specific of ROOL stuff should be fine.

But what about Applications like MIDISupport? Which also replace the MIDI Driver in the MIDI Card Eprom with its own driver?

I think that probably a more reasonable approach (just as an idea), would be that ROOL create a registry of registered Developers (as Apple does) and each Registered Developer generates his/her own keys that needs to be provided to the ROOL registry.

That mechanisms allow ROOL to track which Developer is sloppy with their own keys and remove them for the registry as soon as a security problem comes up (like Apple does too)

This will make things easier for ROOL, the developer and the User and still keeps some degree of security.

Just my 0.5c

@ Rick

…again not impossible to defeat…

May I ask you what exactly would you aim to? There is NO security system impossible to defeat, none. You’ve mentioned Paranoid Linux, also Paranoid Linux can be hacked.

Clearly here there are a lot of people that wish to use RISC OS as a main Desktop. I am not one of them, although if I still love to use it as a Desktop (not my daily driver), but I do respect who wants to use it as a daily driver and for that there is need to INTRODUCE security on RISC OS.

So probably the best way to tackle this is to figure out what should be done, then what could be done (most likely with the minimal initial effort and split it up in multiple phases as for everything else).

But in reality it is not. each new version of DDE comes (quite often) with a new version of ShareClibrary.

That’s so the developer has a distributable version of SharedC that is sufficiently up to date that the features they use are also available to the end user.

In practice the only situations where this distributed version is actually used are on machines that the user has not updated – like someone still using RO4.x or elderly RO5.x (Possibly even RO3.x)

I think that probably a more reasonable approach (just as an idea), would be that ROOL create a registry of registered Developers (as Apple does) and each Registered Developer generates his/her own keys that needs to be provided to the ROOL registry.

I could go with that. That would, possibly provide an alternate route to my suggestion:

To be a secure release it would need to signed by ROOL and be in a state other than beta test. iMx6 fails that one.
I’d suggest that the vendor would need to discuss with ROOL the method for getting a non-beta build that might not be open availability i.e. not appear on the ROOL downloads.

So, yes, that would work. The suggestion eases the burden on ROOL

Rick is concerned about other things:

On the face of it, I am not really convinced that signing stuff is really worth the effort when there are so many other things that need attention first (we’re single core, we barely touch the hardware FP, we pretty much don’t make use of the GPU facilities so can’t play HD video on a lowly Pi or Beagle, …

I’d take issue with the word “first” in there. Attention yes, first no.
I’d take a view that alongside is reasonable.

Coo, infinite link text, how did you manage that?

I write links in HTML as I’m sick of trying to work out how textile parses punctuation, and I missed the closing tag.
No excuse, was using a Bluetooth keyboard so I can’t even blame autocorrect… ;-)

So are you suggesting ROOL to sign every existing Application as well?

That’s the thing, isn’t it? If signing apps is necessary, then there either needs to be an override mechanism or somebody has to sign everything that currently exists and get those versions distributed instead of the current ones.
Excuse me if I feel it’s a cluster<beep!> in the making.

which Developer is sloppy with their own keys

The problem with this is that either the OS needs to accept all legitimate keys, or it needs a mechanism to keep an eye on what keys are acceptable, at least daily.
This is par for the course with Android and iOS as these sorts of things get updated quietly in the background (and burn up a good few megabytes in the process), but such a thing would be alien to RISC OS.

Even then, revoking keys is fraught with complications. https://www.theregister.com/2018/03/01/trustico_digicert_symantec_spat/

There is NO security system impossible to defeat, none.

True, but some are solid enough that they can be left on open public facing networks to act as servers. Sometimes, even having physical access to the device still presents serious challenges. Depending upon what you are trying to access, taking a knife and hacking off the owner’s finger might be a much simpler proposition than figuring out how to read an encrypted filesystem from a flash chip soldered to a motherboard the size of a tic-tacs box.
[like I said, nothing is impossible, it just might require some lateral thinking]

and for that there is need to INTRODUCE security on RISC OS. […] is to figure out what should be done, then what could be done

The main point is that bolting on some encryption and signatures may make things a little safer, but don’t confuse increased safety with increased security as what we’re discussing is akin to attaching wings to a bicycle and trying to call it an aeroplane.

What should be done is a rewrite. However, realistically……

I’d take a view that alongside is reasonable.

I would too, if we had a team of developers. Given that we don’t, and to my knowledge nobody has won the lottery to pay for developers (wasn’t that Charlotte’s original question?), things will need to be prioritised.

If you containerised the OS so each task had a separate instance or our current single context OS, they could replace any modules they liked and not affect anything else.

That’s fair enough for legacy applications running in a compatibility layer. They can hack away at their virtual environment in any way they like, and not do wider damage.

But it’s not a practical solution moving forwards. Many modules require low level hardware access, and allowing applications to introduce their own is a recipe for privilege escalation. Isn’t a better solution that modules not requiring low level access become something akin to Windows DLL files, modules inherently requiring low level access and having general utility become part of the OS, and everything else goes in the bin?

Another difficult question is how fit for purpose is the general “ethos” of the API? Could a modern API sensibly follow it’s basic form and structure, or would it be hobbled by such a requirement?

@ Rick

The problem with this is that either the OS needs to accept all legitimate keys, or it needs a mechanism to keep an eye on what keys are acceptable, at least daily.

Yes that’s exactly what I am suggesting and we can do it outside of RISC OS entirely, let’s use EL0 and the Secure enclave ARM already offers (for example) and use something like genode for the job and make RISC OS use it as an API and just reinforce the execution or not depending on the response from Genode in the secure area which is also enforced by the Hardware to be more secure and so very hard to access.

Again this is an example and yes Genode may requests update from ROOL on a daily bases making sure revoked apps signatures also stop being executed at load and provide the user with a meaningful error message IFF the system is not in test-mode.

How’s that sounds to everyone? feasible?

True, but some are solid enough that they can be left on open public facing networks to act as servers.

Absolutely correct, but that kinda leads back to the route of “let’s rewrite RISC OS from the ground up” and that is because of many technical reasons we could discuss, but is this the right place and moment for it?

The main point is that bolting on some encryption and signatures may make things a little safer, but don’t confuse increased safety with increased security as what we’re discussing is akin to attaching wings to a bicycle and trying to call it an aeroplane.

Nobody is confusing safer with secure (that’s probably what you meant there), increased safety is increased security, but i agree is not “secure”.

What should be done is a rewrite. However, realistically……

I am totally with you on this one, but it also feels we are going in circles: Let’s rewrite it from the ground up. No wait is too much work, let’s do something smaller. No wait something smaller is not secure let’s rewrite from the ground up… (meanwhile someone is trying to rise money to push it as a main desktop…)

This may lead to two potential paths: either the death of the OS OR the RISC OS “AROS” situation where a bunch of fed up people will start a project from ground up…

somebody has to sign everything that currently exists and get those versions distributed instead of the current ones.

What about giving the possibility (through various releases) to enable a permissive mode to give time to developers to catch up? And let’s say make it a must for release 5.40 for example?

Also isn’t the unique app-store the direction everyone basically is taking? macOS, Windows 10, Linux KDE, Linux Gnome etc…

@ Steve Pampling

I’d take issue with the word “first” in there. Attention yes, first no.

Sure, and I am with Rick on the priorities, but security is a complex topic and takes time to lay down all the tactics, we are barely starting here…

let’s use EL0 and the Secure enclave ARM already offers (for example) and use something like genode for the job and make RISC OS use it as an API

ARM Trustzone – read a little previously
Genode as the lowest level replacing any other bootloader like U-boot etc – hmm, yes.
That probably removes some variables arising from different hardware

Is it still possible to add ARM instructions in 64bit mode like you can in 32bit mode. ie like adding SWP instruction for processor’s that don’t have it anymore?

Is it still possible to add ARM instructions in 64bit mode like you can in 32bit mode. ie like adding SWP instruction for processor’s that don’t have it anymore?

That sounds like writing a Macro that has an instruction sequence that replicates the action of the original instruction as an equivalent action instruction sequence.

Clumsy wording there but…

Is it still possible to add ARM instructions in 64bit mode

I don’t see why not. An undefined instruction will still raise the undefined insurrection ¹² vector, won’t it? So you need to trap that, work out what the instruction was to be, deal with it, then return.

¹ Autocorrect thought that’s what I meant. I liked it, so I left it be.

² Undefined insurrection – soon to be the current president of the United States and his delusional enablers.

There is a example on Adrian Lees Aemulor web site.
I wonder if the idea would work to extend instructions on 64bit ARM.

Hmm -On the Aemulor page -seems there is a Aemulor version for the StrongARM RPC.

@Pablo

Could you please explain which type of containerisation are you envisioning?

Docker-like? So having a new RISC OS Kernel (rewritten from scratch, multi-core etc…) that runs in EL2 and supports guest RISC OS systems where the guest offers an API compatible with Classic RISC OS Kernel to the Application? If so how are we going to reconcile the various Apps on the WIMP? Rewriting the WIMP to finally be what it should have been and remove all the pieces that should belong to the kernel?

That’s the one. We need a new HLL, multi-core, multi-thread OS anyway, when we have the kernel, device drivers and a Wimp, we could then run most of the rest of classic RISC OS in a container (possibly also fixing the lack of 32 bit privileged modes at the same time). There would be a separate container spawned for each classic RISC OS application that is run, so instances of the classic OS are isolated, meaning the single context legacy APIs doesn’t have to be re-written. The old Wimp would be stripped down to just provide the legacy API, but use the Wimp in new OS to give a desktop with the applications from all the containers. The big issue – as ever – would be implementing Wimp message passing, appearing to honour deterministic response legacy applications expect, but with applications in pre-emptive containers on multiple cores.

@ Colin

Is it still possible to add ARM instructions in 64bit mode like you can in 32bit mode.

Yes, however I would also sync up with Jeffrey on the way to use Undefined Instruction Handlers (that’s how ARM calls such property).

The reason I mention this is because with the introduction of multi-core support we need to understand how the MMU is going to be managed. For instance if only core 0 executes Kernel code and the other cores don’t then they may not have access to the memory zone where you mapped the bytes for the undefined instruction if that instruction is set to be available in EL1.

If the case above is valid, then when the core 3 detects an undefined instruction it may not be able to handle it as you would expect.