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

[Fats]

It is not just that it breaks existing software. It is not possible implement memory protection without complete redesign of API.

I disagree here. I think it would be possible to have minor changes to the API and provide memory protection to programs that follow certain policies. By the latter I mean no data allocation on the stack that has to publicly available, obey the MEMF_PUBLIC/MEMF_PRIVATE meaning, etc.
Programs could in the executable or during start-up indicate that they follow these policies (with the consequence they may be killed when not following them). Programs not having this indicator won't be able to have MP.
For this to work you have to implement a MP that fits with the Amiga API. This means not trying to enforce the Windows/Linux MP with address spaces for each process/task but getting your inspiration from single address space operating systems and similar systems.
The main extension of the API would consist in extending the memory pools API so programs can indicate which other programs may access certain memory pools in read and/or write mode.

greets,
Staf.

[Piru]

@Fats

Such MP would be quite pointless to be honest (any non-MP app could easily nuke the whole OS or other apps, including the MP aware ones).

How would the OS know if the caller if MP aware? What about 3rd party libraries the app might use? (remember that with AOS library stuff executes directly at the callers context). If one thing would use the flags wrong it'd lead to very hard to spot bugs.

You also forget that in order to have MMU access limitations to certain memory areas they need to be aligned by page size (start & len). With a shared global memory space OS this leads to massive address space fragmentation. And not all memory is allocated via memory pools. In short: You'd need a massive overhaul of the APIs and rewrite the apps anyway.

The issue of MP has been debated for at least 15 years. The best you can get is the mmu.library protected executables. It protects code and read only data. Anything beyond that would require massive overhaul and API redesign, plus app rewriting.

From time to time some individuals come up with claims of generic trouble free MP for amigaos. Needless to say none of them have ever delivered. Some nameless OS even falsely claims to have MP while it really doesn't. Hint: The same OS was supposed to get automatic stack enlargement.

[Amiga_Nut]

Windows may have memory protection since XP (as well as all versions of NT of course but that's not a desktop OS) BUT Windows still gets ass raped at the mere sniff of a TCP/IP connection so why is it so important?

[B00tDisk]

Windows may have memory protection since XP (as well as all versions of NT of course but that's not a desktop OS) BUT Windows still gets ass raped at the mere sniff of a TCP/IP connection so why is it so important?

[persia]

@Amiga_Nut

[lsmart]

@Fats

Such MP would be quite pointless to be honest (any non-MP app could easily nuke the whole OS or other apps, including the MP aware ones).

How would the OS know if the caller if MP aware?

You could sandbox all non MP apps into one blob. A simple tooltype or binary chunk could flag an app as MP-aware. A new programs private memory would always be secure. This would apply to workbench and new kernel as well.

But let´s remember. Amiga OS has in the past worked pretty well without memory protection. So as of now it is of lesser importance than some might believe.

[LoadWB]

So as of now it is of lesser importance than some might believe.

I would quickly argue against this point at the very least for security sake.

[itix]

I disagree here. I think it would be possible to have minor changes to the API and provide memory protection to programs that follow certain policies. By the latter I mean no data allocation on the stack that has to publicly available, obey the MEMF_PUBLIC/MEMF_PRIVATE meaning, etc.

Why this MEMF_PUBLIC insanity? There should be no reason why application should use this stupid brainfart. Remove memory usage restrictions and you are closer to real MP.

Of course all software I have written for Amiga allocates data on the stack and never cares about MEMF_PUBLIC. Believe it or not this coding practise works just fine. It works just fine even on Linux and Windows.

Programs could in the executable or during start-up indicate that they follow these policies (with the consequence they may be killed when not following them). Programs not having this indicator won't be able to have MP.
For this to work you have to implement a MP that fits with the Amiga API. This means not trying to enforce the Windows/Linux MP with address spaces for each process/task but getting your inspiration from single address space operating systems and similar systems.

It could be done using UAE kind of solution. Run every program in its own sandbox.

The main extension of the API would consist in extending the memory pools API so programs can indicate which other programs may access certain memory pools in read and/or write mode.

This is only minor detail. It does not fix the OS.

[psxphill]

With a shared global memory space OS this leads to massive address space fragmentation.

You can alleviate that by virtualising the address space, although that causes other problems.

[psxphill]

Windows may have memory protection since XP (as well as all versions of NT of course but that's not a desktop OS) BUT Windows still gets ass raped at the mere sniff of a TCP/IP connection so why is it so important?

I ran NT4 as a desktop OS, then switched to windows 2000.
Back then it was no more vunerable than any other OS.
 
These days I wouldn't trust any other desktop OS.

[Piru]

You can alleviate that by virtualising the address space, although that causes other problems.

Indeed. The amiga APIs (and thus apps) are full of dependencies of single global memory space (you can add tons of various caller passed structures to system for instance, say PutMsg().. the struct Message will be added to foreign struct MsgPort. There are no strict rules how to allocate either. Many apps allocate them from stack, and that is perfectly legal with AmigaOS). It'd never work... Unless if you redesign the whole API, which in this plan was supposed to be avoided.

[AlexC]

The funny thing is that Microsoft team had similar problem in Windows 3.x era and they did it solving all those problems. It's a common knowledge and in era of virtualization support in modern CPUs this should even not be discussed further but just be done. I can't imagine any commercial OS for home users or for business without MP today. I can think of some uses in embedded market without it and people are still using DOS today so in a long run you can live without it, but than you are filling niche in dying market.

[Piru]

The funny thing is that Microsoft team had similar problem in Windows 3.x era and they did it solving all those problems.

To be fair DOS virtualization is trivial compared to AmigaOS.

[AlexC]

To be fair DOS virtualization is trivial compared to AmigaOS.

True. I don't compare DOS with AmigaOS but with Windows 3.x problem - mind you that they even had problem with different types of memory to solve which protected mode helped to fix. Anyway my point is that most of issues in term of theory has been solved already and this is strictly implementation problem in terms of producing code. There was a similar case in area of memory allocator when AmigaOS got it's own implementation of slab allocator and swap to make it more advance and efficient (which was a very wise move BTW).

[Piru]

True. I don't compare DOS with AmigaOS but with Windows 3.x problem - mind you that they even had problem with different types of memory to solve which protected mode helped to fix. Anyway my point is that most of issues in term of theory has been solved already and this is strictly implementation problem in terms of producing code.

Not really, unless of course if you break the backwards compatibility and run old stuff in a sandbox that is.

There was a similar case in area of memory allocator when AmigaOS got it's own implementation of slab allocator and swap to make it more advance and efficient (which was a very wise move BTW).

Slab allocator is rather poor generic allocator, and I sure hope it isn't used as one. There seems to be great confusion about this, and everyone seems to repeat the slab mantra without really understanding the fundamentals. Slab cannot be used as a generic allocator, nor is it intended as such. I find it rather surprising that slab has been underlined so much in the new AmigaOS memory system, the actual kernel memory allocator is far more important. The original AmigaOS allocator used First Fit algoritm which was okay for the first couple of minutes of system use, but degraded to crawl after some time. It'd be rather important to know if this has been replaced with something better.

Two Level Segregate Fit on the other hand is way better, as demonstrated by TLSFMem patch and MorphOS TLSF memory system. TLSF is a generic memory allocator with constant allocation / deallocation time, regardless of the memory fragmentation.

[Arkhan]

Windows may have memory protection since XP (as well as all versions of NT of course but that's not a desktop OS) BUT Windows still gets ass raped at the mere sniff of a TCP/IP connection so why is it so important?

My entire school was running NT in all of the labs.  We were using the OS, on a desktop!  :roflmao:

There was memory "protection" before the days of NT/XP, but it wasn't nearly as secure/effective.  It was still there.  sort of.


Come try to ass-rape my windows boxes with a mere sniff.  I'm sure you will do your usual and mass facepalms will reign forth, followed by

:laughing::laughing::laughing::laughing::laughing: