Coldfire AGAIN

[JetRacer]

You really got him there HenryCase; no Amiga user would ever recall any of the weeks last 57 gurus and which of the 3 OS versions he used at the time :-)

[HenryCase]

@JetRacer

The different versions of AmigaOS aren't equally stable, so my question still stands.

[Einstein]

HenryCase wrote:

When was the last time this happened to you, and what version of AmigaOS were you using at the time?

Eons ago, since I don't take the "OS" serious so to say, in order to consider it useful (lol).

And there is no difference between any AmigaOS since *there is no memory protection*.

[Einstein]

JetRacer wrote:
You really got him there HenryCase; no Amiga user would ever recall any of the weeks last 57 gurus and which of the 3 OS versions he used at the time :-)

Ofcourse not :roflmao:

[Einstein]

HenryCase wrote:
@JetRacer

The different versions of AmigaOS aren't equally stable, so my question still stands.

It's pretty irrelevant for how long the different versions of AmigaOSs can stand on their feet before collapsing, since the supreme champions in the arena are the tasks :-)

[AeroMan]

Why all the discussions about doing something new to the Amiga deteriorates in no-one-wins Windows vs Linux vs Mac wars ? :-(

Yes, AmigaOS has no "memory protection", but for some reason those blue screens and lock ups keeps telling me that there is something wrong with Windows "memory protection"... :-D

Can we go back to Coldfire ?

[Einstein]

AeroMan wrote:
Why all the discussions about doing something new to the Amiga deteriorates in no-one-wins Windows vs Linux vs Mac wars ? :-(

Because.. (quoting you)

Yes, AmigaOS has no "memory protection", but for some reason those blue screens and lock ups keeps telling me that there is something wrong with Windows "memory protection"... :-D

If something goes wrong *inside* the *kernel* (hint: buggy drivers) then the kernel will "crash", this because modules (drivers) that are loaded into the kernel "become" a part of the kernel, and hence run in kernel mode, therefore they are privileged to destroy data in the kernel space, generally speaking. This is very different to processes that run in user space, those cannot {bleep} around in kernel space and pages which they have not been mapped to their virtual adress space. Hence no normal app can give windows "blue screens", in contrast to AmigaOS tasks/processes about which the story is pretty obvious.

Can we go back to Coldfire ?

You are free man, but why enter a discussion and ask for permission to leave it ?

[AeroMan]

Ok, I recognize it was my fault to express my frustration with Windows problems, and I apologize for that, even if I don't agree with you.

I promise not to be part in those issues anymore :-)

Can we go back to Coldfire ?  :-D It was getting really interesting...

[HenryCase]

Einstein wrote:
And there is no difference between any AmigaOS since *there is no memory protection*.

Not true. AmigaOS4, MorphOS, AROS64 all have at least partial memory protection. I am currently investigating how easy it will be to add full memory protection to AROS (without throwing away AmigaOS 3.1 API compatibility), and so I asked you which version you had used so I could get an idea of the stability compared to the other memory protection options.

So I'll ask again, which version of AmigaOS were you using?

[bloodline]

HenryCase wrote:

I am currently investigating how easy it will be to add full memory protection to AROS (without throwing away AmigaOS 3.1 API compatibility),

The answer is: Not very. i.e. Impossible. While the exec design team clearly envisiaged memory protection at some future time... none of the rest of the OS design team did (I think intuition alone is a very bad boy!), and public/private memory flags were never enforced.

Tasks and libraries happily pass memory pointers around without a care in the world.

[Karlos]

Memory protection exists to clean up the mess of bad coders...

*runs away*

[HenryCase]

bloodline wrote:
The answer is: Not very. i.e. Impossible. While the exec design team clearly envisiaged memory protection at some future time... none of the rest of the OS design team did (I think intuition alone is a very bad boy!), and public/private memory flags were never enforced.

Tasks and libraries happily pass memory pointers around without a care in the world.

That is useful information to me bloodline, so thank you for that. None of what you describe makes retrofitting memory protection impossible though. Let me explain...

The memory doesn't have to flag whether it is public or private as long as the API functions asking for memory space are not allowed direct access to the memory. You put an OS layer inbetween memory allocation functions and the real memory. This MMU gives the memory allocation functions the impression that it is writing directly to the memory, when in reality it is controlling memory allocation/deallocation and protecting unwanted memory access.

For those memory functions called without a flag, the memory status is set to private by default. You then have the issue of inter-program communication. For this, you want to allow the programs to attempt communication, but you want to prevent incorrect values being entered into the program space and potentially crashing the OS. You allow the value to be passed by the first program, but the MMU checks to see if the value is valid before it passing it on to the second program.

For the few programs where this method is not suitable (where you need as much speed as possible for example) the MMU can either be switched off or the program can be patched. The MMU will only be known to the new kernel and the user, the API functions will not be aware of its existence, so they will not mind using non memory protected mode.

Those are my ideas as they stand at the moment. As I said I am still conducting research into the feasibility of a memory protected AROS.

Do you think my ideas are sound in principal?

[bloodline]

HenryCase wrote:

bloodline wrote:
The answer is: Not very. i.e. Impossible. While the exec design team clearly envisiaged memory protection at some future time... none of the rest of the OS design team did (I think intuition alone is a very bad boy!), and public/private memory flags were never enforced.

Tasks and libraries happily pass memory pointers around without a care in the world.

That is useful information to me bloodline, so thank you for that. None of what you describe makes retrofitting memory protection impossible though.

It does if you want all your old software and large parts of the OS to keep working... :-D

Let me explain...

:nervous:

The memory doesn't have to flag whether it is public or private as long as the API functions asking for memory space are not allowed direct access to the memory.

When you request memory from exec you are supposed to flag the memory if it is to shared or private. Although in AmigaOS this actually does nothing (due to the early machines not having an MMU), this tells the OS that the memory should be allocated in either the task's private address space or if it should be allocated in some public memory pool (where anyone can mess around).

Due to the lack of MMU, these flags were never enforced so no amiga software actually bothers to set them properly... Enforcing them nnow after 20 years would break a lot of apps.

You put an OS layer inbetween memory allocation functions and the real memory. This MMU gives the memory allocation functions the impression that it is writing directly to the memory, when in reality it is controlling memory allocation/deallocation and protecting unwanted memory access.

I don't understand... The way memory protection would work is that each task gets it's own address space... in effect each task gets up to 4gig of address space to itself. I shall expalin the reprocussions of this later...

A good book on how MMU's work should give you a better understanding... The intel developer docs are a great place to start!

For those memory functions called without a flag, the memory status is set to private by default.

Well that would break EVERY app, since it is the exact opposite of the current situation... for there to be any hope of this working at all... the default behaviour needs to be the same as current behaviour.

You then have the issue of inter-program communication. For this, you want to allow the programs to attempt communication, but you want to prevent incorrect values being entered into the program space and potentially crashing the OS. You allow the value to be passed by the first program, but the MMU checks to see if the value is valid before it passing it on to the second program.

One of the great things about AmigaOS is that is places no restrictons on what is passed in an exec message... In effect the OS has no idea what the programs are sending to each other. (it's the same problem as the parasite emulator we discussed before).

Now here is where the problems begin... You have two tasks, both have their own address spaces... one task sends a pointer to a data block to another task in a message... that pointer is meaningless to the receiving task, since the pointer is either not vaild in its address space or pointer for somthing completely different!

The only way around this is to have a public pool of memory mapped to the same address window in all task address spaces... but since the public/private flags were ignored this can't work.

For the few programs where this method is not suitable (where you need as much speed as possible for example) the MMU can either be switched off or the program can be patched. The MMU will only be known to the new kernel and the user, the API functions will not be aware of its existence, so they will not mind using non memory protected mode.

You can't just switch off the MMU once it is on... the whole integrity of the memory structure is maintained by this device... Switching it off would leave the memory in effectly a random jumble of 4k blocks that used to mean something...

Those are my ideas as they stand at the moment. As I said I am still conducting research into the feasibility of a memory protected AROS.

Do you think my ideas are sound in principal?

Not really :-)

MMU's are hard to get your head around at first but some solid study and a lot of running it out on paper with a pencil will give you a good idea of the issues here...

[Hans_]

bloodline wrote:

You put an OS layer inbetween memory allocation functions and the real memory. This MMU gives the memory allocation functions the impression that it is writing directly to the memory, when in reality it is controlling memory allocation/deallocation and protecting unwanted memory access.

I don't understand... The way memory protection would work is that each task gets it's own address space... in effect each task gets up to 4gig of address space to itself. I shall expalin the reprocussions of this later...

A good book on how MMU's work should give you a better understanding... The intel developer docs are a great place to start!

You don't need to create separate memory spaces to have full memory protection. In fact, now that many CPUs have 64-bit addressing, there are those who argue that a single linear address space is a good idea. Doing this would allow the existing messaging system to work fine, with the added restriction that programmers do need to mark the appropriate memory as shared.

In order for Amiga OS to have full memory protection whilst still allowing old software to run, there is only one option: place the old apps in a sandbox. There the old apps can do all the naughty things that they used to get away with because the rules were never enforced. Unfortunately, this does mean significant rewrites of some OS modules such as intuition, which didn't follow the rules either.

Hans

[Kronos]

"the existing messaging system" would have to be updated to 64Bit in order to make full use of it, but that would require a recompile.


Wether it would actually do anything in regard to MP is questionable and would atleast require further measures (which will break source-compability too).

[HenryCase]

bloodline wrote:
MMU's are hard to get your head around at first but some solid study and a lot of running it out on paper with a pencil will give you a good idea of the issues here...

I am studying memory protection, but as you failed to grasp my ideas correctly allow me to try and explain them again...

You can't just switch off the MMU once it is on... the whole integrity of the memory structure is maintained by this device... Switching it off would leave the memory in effectly a random jumble of 4k blocks that used to mean something...

Yes you can. Imagine this scenario. You have two kernels available MP-Exec (Memory Protected Exec) and Exec (the standard no memory protection version). You've started running a program, but need it to run faster. When you give the command to switch from MP-Exec to Exec (I know this would remove memory protection for all processes), what effectively happens is that the MMU updates the 'virtual' memory addresses with the real memory addresses (like saying to the program 'here's where your data was'). Once this process is complete a kernel switcher program takes over, freezing all processes and keeping the memory as it was (kind of like when you put a laptop into hibernate). The kernels are switched and the processes and memory are unfrozen. The programs don't see any difference because the APIs of MP-Exec and Exec give the same results.

I really can't see a problem with what I've described, perhaps you can?

One of the great things about AmigaOS is that is places no restrictons on what is passed in an exec message... In effect the OS has no idea what the programs are sending to each other. (it's the same problem as the parasite emulator we discussed before).

But this can be changed by adding an MMU layer to the kernel and updating the kernel functions, so it's not an issue. Of course no memory protection gives you more freedom, what I am describing is a way to add memory protection for those who want it (which seems to be a lot of people).

bloodline wrote:
Now here is where the problems begin... You have two tasks, both have their own address spaces... one task sends a pointer to a data block to another task in a message... that pointer is meaningless to the receiving task, since the pointer is either not vaild in its address space or pointer for somthing completely different!

As the MMU is dishing out memory, it knows what kind of data will be valid for the space. So, for example, if you try to pass a message suitable for a  graphics routine into a memory space designated for sound functions then the MMU will not allow it. This is just one example, there will be other protection measures in place, such as if a program crashes you could limit the crash to its own allocated memory space, seeing as all reading and writing of memory goes through the MMU.

bloodline wrote:
The only way around this is to have a public pool of memory mapped to the same address window in all task address spaces... but since the public/private flags were ignored this can't work.

FYI, that's not what I'm trying to propose.

bloodline wrote:
I don't understand... The way memory protection would work is that each task gets it's own address space... in effect each task gets up to 4gig of address space to itself. I shall expalin the reprocussions of this later...

Don't understand? Okay, this is how it works...

When an API call requests a memory space (doesn't matter if it has flagged anything) the MMU layer of the OS looks for a suitable space to store that memory and then tells the API call (I stored your data 0x001 here: 1F2C, or whatever). The point is, that doesn't have to be where the data is stored, the app just has to think that's where it is stored. The MMU has a look up table linking the 'virtual' location with the real memory location. When the memory stored at 1F2C gets called the MMU then fetches the real data...

My laptop battery is about to die. I do have more to say but I'm hoping the penny has dropped by now. I'll be back later, feel free to comment on what I've said so far.