What is memory protection and why is it so hard to implement for the AmigaOS?

[vidarh]

I'd argue, that as a single-user computer, MP on the Amiga hasn't been missed by the users.  MP on the amiga is a more or less academic discussion that interests the (few) developers every now and then. IF you want to run legacy 68k software, hell even PPC software, then  do it like we always have.  Really.  Just remember to save regularly.

It hasn't been missed that much because the users that are still using AmigaOS have largely gotten used to working around it and/or sticking to applications they know are "safe".

It's battered wife syndrome. It "works fine" as long as you tiptoe around and avoid doing any of the many things you know might cause things to blow up, and explain away the bad things.

That works for existing users, who fell in love with AmigaOS when the alternatives had the same problems. Even some of us "returning" users might be able to tolerate it. Not so much everyone else who don't know/understand/care about what things they should not do and what programs they should avoid and so on.

[vidarh]

Message passing is only minor detail in OS design. What about features like AddPort(), AddSemaphore(), AddTask() and other system calls? How do you protect system against rogue applications? I could add dummy uninitialized message port with invalid name tag. The entire OS could crash when it scans ports next time.

Start with total isolation per app. Break down just the isolation you need to get a functioning system, bridging messages where necessary.

Most Amiga apps don't need to share all that much information between them outside of a well defined set of messages to system services - ARexx messages, shared access to the same file systems and devices, windows being composited onto the same screens, input events. That's more or less it for the vast majority of applications.

Many of these can run as separate tasks/threads in the same "sandbox" as the applications that uses them. It is not necessary for the console.device to run in it's own address space on Amiga OS for example. Many other pieces of system code can reasonably run in the applications address space, further limiting the types of messages that needs to be possible to bridge to other processes.

So yes, you could add a dummy uninitialized message port with invalid name tag, and in the proposed model it would take down the tasks running in that one process for that one application, instead of taking down the entire OS. For "cross-process" message ports the kernel would necessarily need to do careful validation of all arguments.

[vidarh]

What you seem to be suggesting is "emumiga" for all apps, not just 68k ones...

Sort of, maybe... Emumiga (as well as Janus UAE and for that matter AROS hosted) is at least a good "proof of concept" that validate part of the idea.

Unlike Emumiga or Janus UAE, this sandboxing obviously wouldn't need to emulate the CPU or custom chips. It also would need far less bridging work since it doesn't have to deal with endianness issues. Compared to Emumiga the overhead would be trivial.

Both UAE and AROS hosted also already demonstrates the viability of part of the bridging (e.g. sound, filesystem access and input events are/can be bridged from the host, and can be shared across multiple instances of the hosted system). Janus UAE takes that further by also bridging individual windows to windows on the host instead of opening a single window for the emulation.

[vidarh]

But you would have to start new instance of console.device for each sandbox. And not just console.device but almost every other OS service. Drivers must get moved out of sandbox of course.

As with most things on AmigaOS, console.device is extremely lightweight, and contains minimal state. The vast majority of the "cost" of the console.device is the code pages - which are trivially shared - and the data structures for each individual console unit, which aren't shared no matter what. console.device is a perfect example of a device that don't need a separate sandbox, but can run in the same context as the application that opens it.

What about USB stack? I dont think it could stay inside this sandbox. But if it is outside sandbox how it runs? How do you modify USB stack to run there? Or is it just its own box? How about its own drivers?


It wont be easy

Why do you think it needs to be modified to run in its own sandbox? What is needed is a thin shim/bridge for messages between users of the USB stack in other address spaces and the stack itself. This is not much different than, say, the UAE or hosted AROS sharing of the host filesystem with the sandboxed apps.

And it's the same approach for any shared resource.

I dont think old PutMsg() would be suitable for cross process communication anymore so you would define new API to do that, anyway...

This can be dealt with for current apps either by adding information to the message ports, or by creating proxy ports, but it's possible it'd be more efficient to provide a new API for new apps.

[vidarh]

Aaaeee, buggy forum software deleted my posting.

So only short question now: if USB stack mounts a USB masssstorage device woudnt filesystem for that USB drive run in UBS sandbox context?

That's an implementation detail / performance vs. stability vs. development time tradeoff. But yes, that's one option. Another option is for the USB stack to be modified to spawn the filesystem in a separate sandbox and communicate via a cross-sandbox port.

Consider this: On a typical Linux system, almost all filesystems (except FUSE filesystems, and they're not used much) and all drivers run in the kernel context with 100% access to the entire system. Only applications are segregated. That's enough to get sufficient stability.

While the Amiga model in theory lends itself well to separating filesystems from the core OS, I think filesystems are less likely to affect system stability than random apps a user installs - for starters there are fewer of them, and they receive more widespread testing since if they fail they not only impact the system uptime but potentially corrupt data...

In other words, while the purist in me would love to see every task in it's own address space, segregated from each other, the pragmatist in me sees that that's neither necessary nor practical...

It's down to finding a happy medium that provides enough protection for stability on par with modern OS's and little enough to keep the 'cost' (in developer time and overhead) down.