How can executables work when being thrown into different addresses on 68000 ?

[Fats]

Such that when Exec is instructed to load an executable. It will copy the code to the allocated memory. Then Exec will use the table list of addresses and modify all address references..? before executing the code.

BTW, also AmigaOS4, MorphOS and AROS use relocatable binaries.

[Fats]

By tradition or need? PowerPC has MMU asfair?

The need for MMU for multi-tasking OSes has grown when OSes evolved from single task to multi-task. Originally computers were single task with code hard linked to a certain start address. For the first multi-tasking OSes the whole process and it's state were swapped from memory and the next process image loaded. Next step was introduction of MMUs so programs could still think they were single task but actually were multi-tasking.
If you don't need this legacy there is no reason to not relocate the binaries during load. Some people think you need multiple adress spaces in order to provide memory protection. This is false, see SASOS for more information.

[Fats]

Some people think you need multiple adress spaces in order to provide memory protection.

Who thinks that? Lots of microcontrollers provide limited memory protection without an MMU. I.e. write to address range X in user state causes an exception.

All those people who claim you can't introduce memory protection in amiga OS without breaking backwards compatibility. They make this claim because of taking memory protection by virtual address spaces as used in Windows and UNIX/Linux as a reference.

[Fats]

You must have misunderstood memory protection discussion on Amiga forums.

I don't think so
If you mean that you can't force memory protection on current compiled programs I agree.
I even agree that for programs who want MP, it probably means some more work then just a recompile although changes needed I foresee seem to be much less than what most other people think.
What I don't agree with is that MP can't be introduced in an Amiga like OS without breaking backwards compatibility for already compiled programs.

I do think it is possible for new compiled programs to indicate to the OS they are memory protected (and resources tracked, another feature heavily wanted). There likely will be some restrictions in usage of certain functions or some existing functions will behave different when called from a memory protected program. f.ex. auto stack extension will need that only private data is put on the stack.
With this approach I think it should be possible to come to a state that memory protected programs will catch bug and gracefully exit without keeping resources in the system.

As a first step I see the introduction of memory contexts and make memory pools so that they can be inaccessible from certain memory contexts, read-only from others and read-write from again others. I you have done this, you have basically introduced memory protection in the OS (unfortunately no users though ).
Next step is to gradually see case by case, library by library, driver by driver how this feature can be used and with the least behavioural impact on existing code.
Now that would bring back Research in AROS and IMHO much better than finding excuses using the hardest corner cases to not start the work.

I even agree that having a hacker proof MP system e.g. that is resistant to programmers who want to deliberately circumvent the MP will be another job of much bigger proportions and likely difficult to introduce in a legacy OS like Amiga OS. But I would already be satisfied with MP as discussed in previous paragraph.

greets,
Staf.

• The 'why-don't-you-do-it-yourself' reply is unnecessary; my mind is currently occupied with other things not or only indirectly (NG) Amiga related. But if somebody feels the itch don't hesitate to contact me.

[Fats]

In MP system there should be no concept of public memory at all. Public as in "memory that any task can alter at any time".

I don't see what is wrong with providing public memory in a MP OS. Programs should be able to not need it or use it though.

There is no true memory protection if task Y by accidentally writing data to address X can cause entire operating system to crash. For example try memset(SysBase, 0, 0xffffffff) and see if the system can survive from that.

SysBase could be read-only for the MP programs and they will just be killed if they try to do the above. The non-MP programs can still step on each other toes but won't be able to bring down the MP ones and the part of the OS that is also MP converted. I don't see why some clever MMU trickery shouldn't be able to do that.

I would just forbid use of low level APIs like Intuition and migrate software base to use higher level abstraction (i.e. MUI).

I would not go that far and you also want to retain the possibility for devs to program their own gadgets which will need lower level functions. I don't want the GUI framework become part of the kernel.

One other thing I also certainly want to keep is messaging by pointer passing. IMHO an OS not doing this can't be called an Amiga-like OS.

Introducing more memory types is just insane adding more unnecessary complexity. AllocMem() with MEMF_ANY should be enough.

I personally want some more fine-grained access rights than the classic process based MP as in UNIX with an additional kernel context that basically can read/write everything. I also would like something that is much less complex than SELinux for defining the access rights.
To me an amiga-like OS has to be micro-kernel and the kernel (e.g. exec.library) should be kept as small as possible. It should just provide the facilities to two tasks to have memory which they both can access but no other tasks can access but the kernel's involvement should stop there.

[Fats]

You can always find a solution to one problem but it is likely to introduce two more. The sun explodes before all that code is fixed and in place with backward compatibility. IMO

I just hope I somewhere find the time, inspiration and transpiration to prove you wrong

[Fats]

Suggestion, make new OS. And write an compability layer.

Linux+ AROS ?

[Fats]

SELinux has little to do with memory protection in the context of this thread.

I have to admit I am no SELinux expert (I just disable it) but what I had in mind when I wrote that is that you use shared memory if two processes want common memory access and SELinux is used to restrict access right to this shared memory.

[Fats]

3) Can programs still isolate *parts* of their data? Yes, they can. Unfortuntely, this part of the data cannot be used to store any type of Os structures, only private data. But still.
...

4) Is virtual memory possible? Not for Os structures. Only for private memory. Reasons are basically that swapping in memory requires a task switch, thus breaks any Forbid() and Disable(), and the Os is not prepared for that.

I also think most of these restrictions can be removed by doing the proper changes in the OS and most of the OS can be MP also.