Authorised writes to OS workspace

I raise this because of the increasing awareness of the need to provide segmentation between the OS and 3rd party software.

Whilst implementing filing system support in ADFFS, I noticed *ScreenLoad (aka OS_SpriteOp 3 ) from a filing system running under ADFFS was triggering an Abort attempting to write to an area in the OS workspace (FFFF2BA8 off the top of my head.)

Looking at the RISC OS source code for ScreenLoad I could see it’s loading sections of the Sprite file into OS workspace. This struck me as a little odd as further down the source its using the RMA when scaling, anyhow, this raised a few hypothetical questions:

• Why is ScreenLoad using OS workspace to essentially load a sprite?
• Where else is it legal to write to OS workspace?
• Why is there no dedicated Dynamic Area and associated Module/SWI’s for temp/scratch space memory?

On the later question, traditionally the RMA has been used for this purpose but this leads to a host of issues from RMA fragmentation and the mixing of code and data, to the RMA having to be User writable. This last point has been raised a few times, but isn’t easily rectified without breaking backward compatibility. You could potentially redirect OS_Module 6/7 to another DA so Claimed memory isn’t in the RMA, but there’s still going to be the odd breakage.

Long story short, should the OS be authorising 3rd parties to write to OS workspace, or should it be done through an intermediary buffer?

Why is ScreenLoad using OS workspace to essentially load a sprite?

Technically it’s the VDU workspace, so ScreenLoad (which is implemented in the VDU driver in the kernel) has full knowledge of everything else that might be using that buffer.

As to why it’s using it – I suspect the original intent was to avoid excess stack usage & RMA allocations.

further down the source its using the RMA when scaling

A recent addition, after I spotted that the fixed-size workspace buffer which it was previously using didn’t have any bounds checking and so certain sprites could overflow it.

Where else is it legal to write to OS workspace?

Anywhere the OS decides it is legal ;-)

Why is there no dedicated Dynamic Area and associated Module/SWI’s for temp/scratch space memory?

Because Acorn.

Long story short, should the OS be authorising 3rd parties to write to OS workspace, or should it be done through an intermediary buffer?

If we were worried about security/stability, using an intermediate buffer would make sense, as would many other things (ensuring all code pages are read-only, avoiding using buffers which are placed on the stack, etc.)

But as it is, I don’t think there are any serious problems with the current approach. I’m guessing that the only reason you’re running into problems is because ADFFS is running the filing system in user mode, which isn’t normal for any filing system.

Why is there no dedicated Dynamic Area and associated Module/SWI’s for temp/scratch space memory?

Legacy. Back in the day there was no such thing as a Dynamic Area (that began with 3.5), so it was just accepted that things would make a billion tiny claims from the RMA, a situation that continues today.

This last point has been raised a few times, but isn’t easily rectified without breaking backward compatibility.

No, we’re pretty much stuck with it if wishing to keep RISC OS as it is now. Maybe when a breaking change comes (64bit?), we can look at doing the whole module thing “properly” with better levels of privilege for code and data and data used by third parties.

ADFFS is running the filing system in user mode, which isn’t normal for any filing system.

Amen. Not only not normal, not right.

I’m guessing that the only reason you’re running into problems is because ADFFS is running the filing system in user mode, which isn’t normal for any filing system.

Well, quite, but you can’t paravirtualise the CPU and then let code run elevated can you!

It wasn’t a problem, I simply added a local implementation of *ScreenLoad that uses a temporary memory allocation. It was whilst coding that, that I wondered where else the OS uses temporary memory allocations and why we’re still reliant on the RMA.

It’s an interesting topic, well, I thought so.

It’s a pity that ‘Modules’ could’t be run in User Mode – (seem to remember early ‘Modules’ swi’s switched to svc Mode when called- ie first instruction was a teqp) so perhaps User Mode was planned to be used in early Arcs.

(I think this was talked about before – ie switching a module to User Mode when called)

And steam came out of ears :-(

I wondered where else the OS uses temporary memory allocations and why we’re still reliant on the RMA.

Doesn’t the OS consider page one (&4000-&7FFF) to be a dumping ground for all sorts of junk? Think about stuff like GSTrans expansion, canonicalising path names, FKey buffers, etc etc.

seem to remember early ‘Modules’ swi’s switched to svc Mode when called- ie first instruction was a teqp

That would be strange, as SWI switches to SVC mode; unless the early ARM design considered something different?
Are you sure you aren’t mixing it up with event handler code? Switching to SVC is not unusual since some events can fire in IRQ mode (and on original hardware, quite possibly FIQ as well?).

ie switching a module to User Mode when called

I would imagine this is “doable” for many modules. Consider my OLED driver. It communicates with the display using IIC calls. It builds the display with VDU redirection (to a 128×64 sprite). There’s literally nothing in there that needs to run in SVC mode…

Doesn’t the OS consider page one (&4000-&7FFF) to be a dumping ground for all sorts of junk?

If memory serves me correctly, Acorn allocated that space as general use temporary memory. I certainly use it all the time when debugging as it’s handy having a known address low down, where you can freely store debug info.

It’s days are probably numbered though, it was mentioned a few times during the Page Zero relocation discussion. I doubt many 3rd party apps used it however, there were a few games that used it during their protection sequence to temporarily store code, but they’re in the minority and don’t really come into the equation as they’re not 32bit compatible.

I suspect the bulk of the use is by RISC OS…all the more reason for a general use temporary memory allocation system that isn’t in the RMA. That said, there’s the issue of apps blocking memory reallocation which I would guess, is why &4000 exists and a block of the OS workspace has been set aside for Sprite operations – odd it didn’t make use of &4000, perhaps it clashed with the filesystems use?

&4000 is the “Scratch Space”, and has the unusual permission that you may use it “if you know you can use it”. ie, if you know which calls will trample on it.

Colin mused

seem to remember early ‘Modules’ swi’s switched to svc Mode when called- ie first instruction was a teqp

No. SWI always goes to SVC mode. The TEQP PC,#3 you remember from all 26bit ROs except Arthur 0.3 is not to change mode but to clear the other flags.

switching a module to User Mode when called

I presume you mean via SWI – modules are started in USR mode of course, but the other entry points must be privileged.

SWIs in particular HAVE to be a privileged mode, because after the module has finished, the SWI handler has to return to the caller, which may have been in a privileged mode. The simplest way to elevate your privilege is via SWI, so in order for a module’s SWI handler to run in USR, there would have to be a SWI called to finish the SWI. Uggh.

&4000 is the “Scratch Space”, and has the unusual permission that you may use it “if you know you can use it”. ie, if you know which calls will trample on it.

The problem being, you have no idea what makes use of it, so its next to useless unless you don’t use SWI’s whilst you’re making use of it!

you have no idea what makes use of it

• ColourTrans, Draw, FontManager, InverseTable, flood-fill
• FileCore, FileSwitch, ADFS
• HeapSort

Things that used to use it:

• GSTrans et al
• Keyboard handling
• RMTidy (and SWI)

There’s some low-level initialisation usage as well but that won’t affect programs.

And yes, there ought to have been an OS_ClaimScratchSpace call much like OS_ClaimScreenMemory.