Help me understand Cloverleaf

promote RISC OS as something fun and efficient to stick on your Pi instead of Linux, to do the things that you do on your Pi

As I said earlier in response to a query of what RO has vs. Linux

Something that runs rather than walks and offers near bare metal access?

If we had better development tools I suspect it would become a popular development/test platform.

It occurs to me that a basic level OS version with an included bespoke application ALL in a ROM image could be quite a popular item.

If we had better development tools I suspect it would become a popular development/test platform.

Probably not, because the rest of the world is a long way ahead. RISC OS doesn’t really have any advantages compared to modern systems if your aim is to get a job done quickly and efficiently, and to have it work reliably. What it does have is that it’s fun to tinker with, if you don’t have deadlines to meet.

As an example, the recent issue with WinEd and SaveAs dialogue boxes took me about a week to track down. Were I working in my usual “paid for” environment, it would have taken as long as was needed to turn on “throw all exceptions” in the debugger, run the code through the problem, and then look at the state of the software when it broke. On RISC OS, I ended up reading the sources for the Window Manager, in assembler and with extremely poor comments, in order to try to find things that I could do to narrow the problem down, then doing the same with the DeskLib library. Finally, I added lots of debug output to Reporter, before trawling through it line by line.

That’s never going to be viable for hobbyists whose time isn’t valuable to someone. Bare metal isn’t much fun if your boss is asking when you’re going to have that thing which was needed last week working properly. Some abstraction and useful debug facilities are much more of an advantage.

It would really need to be maintained and part of the OS releases if there was an outbreak, however. :-)

Good job we are not putting our head above the parapet then …oh no if Cloverleaf is successful then someone will just do it because they can!

Not that I don’t want Cloverleaf or any other RISC OS related initiative to not be successful but if they are, which I hope they are, then it is less obscurity and that presents a different challange then.

Still better to have that worry than face total oblivion as the user base departs naturally due to it’s current demographics.

is very likely to attract some attention.

Indeed. It’s hanging a giant pink blinking neon sign over the door that reads: Go on, I double dare you (if you think you’re hard enough)

It’ll probably get more than one response. Just to ram the point home with a sledgehammer.

promote RISC OS as something fun and efficient to stick on your Pi instead of Linux,

That’s exactly it. We’re not going to compete with the likes of Linux and Windows and their armies of developers and rich ecosystems.
We’re the alternative. The one where you can hack about, get stuff done, break things, but did I mention getting suff done?
Provided that stuff is, for instance, messing around with GPIOs or fiddling with multi-core code for the lulz, as opposed to watching movies.
In this respect, RISC OS is great. You don’t need to fight the OS in order to poke the hardware. And you don’t need to install a 30MiB framework that depends on 100MiBs of other bits of frameworks to work; leading to dreadful latency as your request to prod the hardware has to work through multiple layers.
No, on RISC OS, you map it into a bit of memory (if it isn’t already, like the GPIO module) and you either use the GPIO SWIs or bash the hardware registers directly. It’s basically bare metal with a friendly little OS to help you in your poking and prodding.

RISC OS developed from the BBC MOS, and both are rather singularly unique in that they wanted you to fiddle around inside. The level of detail in the BBC User Guide was quite astonishing in its time (compare other user guides – the Oric-1 is quite well written, but it says little about how the machine actually works because it’s basically a “teach yourself BASIC” book). Under RISC OS all this information ended up in the PRMs which you had to buy, as it was hardly reasonable to supply four bibles with each machine. And that doesn’t even cover BASIC, that’s another tome.

RISC OS is very open, very accessible. It’s total crap in terms of security, but as an OS for hacking¹ on, it’s great. We ought to talk up this angle.

but if you’re not constrained by having to do things by deadlines it can be more interesting and satisfying.

Oh, I don’t know. RISC OS developers seem to have a habit of fighting deadlines in getting stuff ready for shows. “This app here? I’m giving you this to test on Wednesday because I need it all sorted for Thursday because on Friday I’m leaving to make it to the show on Saturday…”

It’s no wonder half of you guys have grey hair. That kind of stress isn’t good for you. :-)

bespoke application ALL in a ROM image could be quite a popular item.

Shouldn’t be too hard – there is already a mechanism for wrapping applications inside modules, used for all the ROM apps.

That said, a ROM image is something that sits on a µSD card these days. So why not just have the app in question arranged to auto-boot as the system starts? That also gives the option of in-situ updates, something that is harder with ROM images.

and part of the OS releases if there was an outbreak, however. :-)

What comes to mind is what does it actually detect? I’m sure there’s a lot of stuff in there that has no relevance to a 32 bit OS. You’ll notice in that thread that it’s being aimed at “RISC OS 3.20”…

You’ll notice in that thread that it’s being aimed at “RISC OS 3.20”…

It may be but as Jon says it is hopefully 5 compliant and should work on anything from RISC OS 2 upwards.

He has even put in a fix Jeffrey Lee found in 2011 but wasn’t implemented as Rob Sprowson decided to withdraw the module, in 2012, from the disc image as there was no support/development for it or the companion Killer cleaner program.

Anyway lots of old discs and downloads still have known viruses on them so I guess having it is good if you are using an emulator and also perhaps ADFFS may introduce some potential ability to infect as well when running older software.

Jon may be able to give an update on his plans in the mean time the boy scout in me says better to be prepared so it is installed on my ARMX6 though it proves how trusting we in this community are at just installing things and that would need to change if a wider audience attracts those who do things for fun.

Shouldn’t be too hard – there is already a mechanism for wrapping applications inside modules, used for all the ROM apps.

I know, that’s why I suggested it. Sort of an embedded OS/app.

That said, a ROM image is something that sits on a µSD card these days. So why not just have the app in question arranged to auto-boot as the system starts? That also gives the option of in-situ updates, something that is harder with ROM images.

Because the ROM image has been built to not allow any extra program(s) to run? Bit difficult to get a virus to run when the whole system OS and application runs from a ROM image that limits the user to specific actions.
That’s why most embedded systems are what they are.

What comes to mind is what does it actually detect? I’m sure there’s a lot of stuff in there that has no relevance to a 32 bit OS. You’ll notice in that thread that it’s being aimed at “RISC OS 3.20”…

Over half an hour since you posted that so by now you’ve downloaded, and been hacking in the binary to see what signature strings are in it…

I’m not sure how best to articulate what I’m going to say next as a selling point for RISC OS, but RISC OS contains no manufacturer or developer, surveillance software that syphons your personal data.

Some of the other things that might be considered as selling points: …extremely fast baremetal operating system, access the desktop in seconds from a cold-start, it has great WYSIWYG software, built-in BBC Basic, …

It’s hanging a giant pink blinking neon sign over the door that reads: Go on, I double dare you (if you think you’re hard enough)

Indeed.

Just for Doug, who seems to be struggling with the point that some of us are making, when you do a risk assessment you combine the likelihood of an event happening with the severity of the outcome if it did, and plan based on that. You probably wouldn’t bother expending time and effort on reducing the likelihood of an already very unlikely accident that would just give you a stubbed toe, but you would definitely do so if the outcome was probably fatal (and under UK legislation, a court would expect you to have done so, or to have documented a very good reason why you didn’t).

We’re not talking people’s health here, but the outcome of a malware incident – especially if it was from someone with a long-harboured grudge who had read Rick’s pink, blinking neon sign – could be extremely bad. Lots of irretrievably lost data, and very possibly lost source code to applications. Would all of the current RISC OS companies and developers remain active and with all of their current products available? Who knows, but we could easily be testing a lot of disaster-recovery setups in anger for the first time.

Is it likely? No, I don’t think it is. Given the severity of a likely outcome if it happened, should we mitigate the risk shown by our assessment? Yes, we should.

Does that mean that we don’t do Kickstarter projects? No, of course it doesn’t.

What it does mean is that we don’t promote them with big, pink, blinking neon signs.

Just for Doug, who seems to be struggling with the point that some of us are making

Not struggling at all and well aware of what is being said and I was replying to a what happened to VProtect.

it proves how trusting we in this community are at just installing things and that would need to change if a wider audience attracts those who do things for fun.

As I said, plus you and Rick say, don’t raise someones interest who will just try and dispprove you are virus free.

As you say risks and mitigations but in this case one mitigation is easy, don’t mention virus free.

@ Steve Fryatt

RISC OS Direct seems to have got it correct: promote RISC OS as something fun and efficient to stick on your Pi instead of Linux, to do the things that you do on your Pi, then wait. You still won’t get everyone, but it’s far more likely to be a positive experience that gets some people looking deeper into what else they can do with the OS.

Totally agree with your entire comment there, just snippet a piece to give ref to which of the many comments :)

@ Others

About Rick’s comment where someone assumed he may have provided a way to write malware for RISC OS… guys the truth is: it’s possible to write a malicious behaving piece of code (in any language included BBC BASIC) without any knowledge of virus development.

IMHO what is dangerous is to make claims that the OS can’t keep and, as others have already mentioned, “security through obscurity” is not security.

On VProtect,
nice to have a V5 for 32bit, most of the malware it detects it’s actually 26bit malware (module based) so it may not work on a 32bit system, but there is some of it I have found that can, so it’s good to have a newer VProtect. However I agree with who said VProtect should become part of RO itself.

Few notes on the use of VProtect: right now (up to release 4.04) that I have anlysed it is not capable of protecting from Keyloggers, malicious scripts (for instance malicious Flash code written for the old Flash plugin, or malicious Java code written for the old JVM released by Acorn). So it seems capable only to protect from old forms of worms and viruses file-based and using Obey to transmit.

There are plenty of damages that can be done via KeyLoggers, Ramsomwares etc. directly to a user and then there are indirect damages that can be done by transforming RISC OS systems into zombies being part of malicious botnets.

Unfortunately is not only a crypto-current mining system the danger for the future.

RISC OS is so superior to every other OS and is completely invulnerable to viruses

Yes and no. ROM (and so shift power on) was invulnerable to virus.
With some signed ROM this part could be rock solid.

Tools to easily make a new ROM with specific applications/modules and sign the whole thing would be great too.
We can imagine people who want to pack a ROM with a network tool (IoT) or a game for example.

Probably not, because the rest of the world is a long way ahead.

Yes, no, not sure. See VB → VB.NET. From simple to impossible.
I could say the same for RealBasic and Xojo.

We have today two type of solutions:
- no code
- too much code

There is still room for some low code solutions.

The “there are enough solutions” is a classic argument.
Basic was the top… until one guy gave us Python… And now others provide Rust.
KBasic was enough… before Gambas… and Gambas enough… before the (excellent) BaCon.

And you don’t need to install a 30MiB framework that depends on 100MiBs of other bits of frameworks to work

I remember that Ashiv did use RISC OS because of this. Large frameworks are also full of hidden bugs that will make your application crashing in a way or another. In the embedded market, bare metal is sometimes more predictable in term of performances, and is easier to maintain.

They did code quite large systems in ASM, Basic and C.

I know, that’s why I suggested it. Sort of an embedded OS/app.

Yep

but RISC OS contains no manufacturer or developer, surveillance software that syphons your personal data

Without an external audit, we don’t know.

Hi guys I want to draw your attention to our new post about sound system
Sound IO

I think one thing we must add soon is user login also. These days all must be private and locked up.

Yes, no, not sure. See VB → VB.NET. From simple to impossible.

I’m not quite sure what this means, but having used VB6, VB.NET and C#, I’d go for C# or, if not available, VB.NET any time. VB6 was properly nasty for anything non-trivial: unsigned 32-bit values; 64-bit values; bitwise operations, and probably stuff I’ve mercifully forgotten. I developed and maintained production test systems whose control was written in the three languages for around 10 or 15 years. It involved interfacing with a lot of specialised hardware and handling the oddball data that it returned. For new systems where we had a clean slate, our team used C# every time.

I’m also fairly confident that had I been looking for a problem like my WinEd one in a C# application, I’d have found it within an hour or two because the debugger would have identified exactly where things were falling over. I wouldn’t have spent a day reading the Wimp source code in an attempt to focus my guesswork for the next week.

Oh, we also had a couple of very legacy systems whose control was written in BBC BASIC for Windows. They were an utter nightmare to debug, not to mention update when external infrastructure changed.

Needs more than that. Whole partition encryption for example.

But there is perhaps a better – intermediate – option:
1/ a lock system to protect all the root directories from writing (!Boot, Apps, Doc). All but “Public” and scrap. Must be done at system level, with a CLI tool to lock/unlock the system. Of course, !Configure should not work while locked.
2/ a user directory (“Private”?), for personal data, with encryption. For example with a specific version of FileShrinker.

In a perfect world, scrap and preferences should be per user if you want to protect all the personal data.
A good first step would be a per user Pinboard configuration.

Technically, we would just need to reactivate the lock function.
http://www.riscos.com/support/users/userguide6/config/lock.htm

But with different parameter: Not on Scrap and Public → Not on Scrap, Public and user unlocked Private directory
Of course, it’s not secured (password is stored in cmos). That’s just for basic security of apps and parameters.
The real security is user data encryption.

Nota: if the admin password is more secured, it’s also a way to be virus proof at user level. Block any apps/script in private and public directories and say goodbye to incoming virus or ransomwares.

They were an utter nightmare to debug, not to mention update when external infrastructure changed.

Of course. But the idea is that we solved these problems… while adding new ones (more complexity).
Our dev solutions only know how to grow and we need to wait for things like Python or Rust for periodic reboots.

I think one thing we must add soon is user login also. These days all must be private and locked up

Agree and I am sure that many on here have stated how difficult that would be due to the amongst other things a lack of privileged user concepts.

RISC OS 6 did do a user type login and perhaps to ensure some compliance it might be good to look at how that was achieved so as to have some carry through but it was not ideal.

Recently RComp have done Lockscreen so you sign in and that does something but is basic and there are ways to see the files which I will not go in to here for obvious reasons.

As David mentioned there is the ability to lock the hard disc until you do a delete power reset of the CMOS that is.

There are tools to encrypt files on RISC OS such as Q-Lock so perhaps that is something else that could be used.

It all depends on what you want from a user login prompt is it to allow multiple users to use the system in safety or is it to protect one user of the system and their data.

All good thoughts on making things appear more secure and what normal users are used to but it might just again get someones interest and it wouldn’t take long to get around if what is done is only a partial implementation and then going the whole hog may just break a lot of things.

Anyway I am sure others have far more relative thoughts on the matter than me but it along with all the rest is something that we do need to consider if we get RISC OS more in the front window than it is today.

First thing would be that one user can protect his computer from bystanders. Raik said that on RISCOS 6 was possible to have multiple users.

one user can protect his computer from his girlfriend or wife

Well thats a unique selling point “RISC OS safe for cheaters to use”

I get what you mean even if the language is more than a little dated and not exactly inclusive :-)

Because the ROM image has been built to not allow any extra program(s) to run?

How would that work? By omitting filing systems? By hijacking ServiceCall &2A?

Bit difficult to get a virus to run when the whole system OS and application runs from a ROM image that limits the user to specific actions.

Emphasis applied to the part the OS isn’t so great at. ;-)

so by now you’ve downloaded, and been hacking in the binary to see what signature strings are in it…

Been hacking something else entirely.

that I have anlysed it is not capable of protecting from Keyloggers, malicious scripts (for instance malicious Flash code written for the old Flash plugin, or malicious Java code written for the old JVM released by Acorn).

It’s a simple virus detector, not a fully-blown anti-virus system.

Besides, quite a lot of anti-virus packages won’t detect a key logger until the specific thing is reported as malicious, because such things as disability aids or IMEs may have business snooping around keypresses and such. Advanced anti-virus tends to use heuristics (behaviour that resembles what a virus does). It’s why I ditched AVG in favour of Avast! a great few years ago – AVG just got to the point where it seemed to thing every damned thing was “potentially a virus”. Including my own programs, that I knew at source code level.

As for Flash and Java – Jesus man, it’s 2020. You deserve what you get if you’re still running that rubbish on a non-sandboxed VM. They were security nightmares decades ago, and generally got worse, not better. Just don’t.

Unfortunately is not only a crypto-current mining system the danger for the future.

We’re safe on that front. Only one core and no GPU acceleration, makes mining coins about as difficult as going up t’mine with t’pick and shovel for 23 hours a day and paying t’mine owner for the privilege (you know how this one goes, right?).

With some signed ROM this part could be rock solid.

-1

Generally ROM signing is intended to lock people like us out of our own hardware.

Tools to easily make a new ROM with specific applications/modules and sign the whole thing would be great too.

So you want the security of having signed ROMs, with the flexibility of being able to easily sign custom ROMs.
So, remind me again, what’s the point?

The “there are enough solutions” is a classic argument.

NEVER! How many window managers are there for Linux now?

Basic was the top… until one guy gave us Python… And now others provide Rust.

<giggle> I think you’re missing a few decades where people used C, C++, Delphi, and some other things I’ve forgotten.

before Gambas… and Gambas enough…

Mom’s ghost is shouting from the graveyard: Who the hell calls their language prawns?

Without an external audit, we don’t know.

Actually, you can check. Hook up a PC to share a WiFi/USB internet connection with the LAN socket (XP could do this, with some damned eccentric IP addressing) and plug the Pi into the LAN socket, then run WireShark Portable and watch what goes on.

Some advanced routers can do this to. Steve probably has a few. I don’t.

These days all must be private and locked up.

With a filesystem that has no concept of user access? It would be like a movie set, a pretty looking house that’s just a façade and scaffolding…

unsigned 32-bit values

Huh? I thought VB’s integers were always signed, making handling big numbers “interesting”.

bitwise operations

Yeah, I’ve never come across a language before (or after) that couldn’t bit shift. I recall one app I created that had to break apart a bitmap into pixels used a lot of integer division. And multiplication to reconstruct.
I would probably cry if I had any idea of the hoops the processor was jumping through in order to do something that ought to be single instructions (hell, even on an x86!).

Nota: if the admin password is more secured, it’s also a way to be virus proof at user level. Block any apps/script in private and public directories and say goodbye to incoming virus or ransomwares.

I don’t think it would prove too hard to work past all of that.
Essentially, apps need to be put somewhere in order that they can be run. And as soon as things get run, well, then it’s potentially game over.

So you want the security of having signed ROMs, with the flexibility of being able to easily sign custom ROMs.
So, remind me again, what’s the point?

To make and distribute ROMs that won’t be changed by someone else without loosing your signature. Of course, if you do not want to sign a ROM, don’t, but a small message at startup “this ROM is signed by xxx”, could help detecting a compromised ROM.

I think you’re missing a few decades where people used C, C++, Delphi, and some other things I’ve forgotten.

I was talking of easy to use languages. Python is clearly the new Basic. And Rust the new Python.

then run WireShark Portable and watch what goes on

… for years, because you’ll never know when the data will be sent.
Telemetry is easy to detect. Real spying is a bit more difficult.

Anyway, no one in the security market will trust a non audited OS.

Essentially, apps need to be put somewhere in order that they can be run. And as soon as things get run, well, then it’s potentially game over.

Virus proof at user level
Of course, if the admin installs a badware…

Anyway, I was talking of an intermediate solution. Not perfect, but not so bad.

The alternative would be encrypted partition support. While booting, you type your name and password and the RISC OS ROM will simply boot on the right partition. Reboot to change of user. Some warm startup techniques could save a few seconds. Hibernation could help too. You can also imagine a common RW partition for Public and a common RO partition for core Boot and Apps (RW only for admin).

Else, a SD card for each user :)

@ Stefan Fröhling

First thing would be that one user can protect his computer from his girlfriend or wife. Raik said that on RISCOS 6 was possible to have multiple users.

Just a note: that is more Privacy than Security.

From RISC OS 4.39 multi-user login was supported up to 6, however it wasn’t a secure mechanism. Also, just for the record, RISC OS 4.39 introduced a basic firewall and obviously came with VProtect. This, at the time, appeared to be a beginning of adding security to RISC OS, but it obviously wasn’t anymore secure than what let’s say Windows 95 had in place, so was already quite outdated back then.

Again not arguing on what you guys want, I believe everyone is entitled to have their own opinions, I fully respect that (and I hope it comes through so). What I am trying to point out is that we should start to list/consider all the layers of logic that needs to be designed and implemented in order to achieve user-facing functions (pretty much what ROOL is already doing on other aspects of the system and that is un-avoidable to get where people wants RO to be).

For example, having a login mechanism means:
1) first to have a way to store “secrets” in a safe way (the password for who has no idea of what I am talking about).
2) #1 comes with encryption, but encryption requires keys and keys have to be stored safely
3) #2 requires the OS to be able to handle an enclave of some sort, on ARM this can be achieved using TrustZone for example.
4) #3 in the case of TrustZone requires the OS to provide an API and mechanisms to store the keys in the Secure Address Space which is NOT accessible from the NON Secure Address Space where RISC OS (or Linux for example) runs in EL1 on the ARMv7 or v8 etc.
5) #4 requires that RISC OS know how to talk with ARM firmware etc. more details here: https://developer.arm.com/ip-products/security-ip/trustzone/trustzone-for-cortex-a

You could get away without points 4 and 5 and use pure software based approach and no Safe Address Space, but that would also make it easier for an intruder to find your password has it has happened for ages on Windows till Windows Vista.

Maybe it’s a good idea to start a thread (or even better a series of threads) on various aspects of Data Privacy and System Security. Just my 0.5c.

Huh? I thought VB’s integers were always signed, making handling big numbers “interesting”.

They are. Time has blurred some of the horrors, but I have recollections of 32-bit flag words from some external hardware where the top bit was quite important to what we were doing.

At least in BBC BASIC you could do bitwise operations to set and clear bit 31 in a semi-logical way… :-)