Coldfire AGAIN

[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.

[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...

[bloodline]

Hans_ wrote:

Kronos wrote:
"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).

Updating to 64-bit would only need to be done on a 64-bit processor. Seeing as that jump is going to break stuff anyway, migration to a 64-bit processor would be a good time at which to make the necessary changes.

At a bare minimum, memory for messages should be marked as shared. Even better, message allocation/deallocation functions should be created that do this. What I was trying to say is that we wouldn't need a completely new message passing system. There would be additional restrictions, but the fundamentals would remain the same. The differences would be enough that old apps would have to run in a sandbox.

Hans

Hans!! There is nothing wrong with the message system, the problem is what is sent in those messages! The OS doesn't know what they contain and they could contain anything! :-)

[bloodline]

HenryCase wrote:

Karlos wrote:
How do you take, say, 16 4KiB pages scattered across the 4G physical address space that an application requested and originally thought was one contiguous 64KiB lump of memory and tell it "here is where your data was" ?

By arranging it into a 64KiB lump before you give memory control back to the program.

Memory allocated in a Memory Protected environment is built up from small blocks of RAM... they are usually 4k in size (this is convenient on a 32bit system) and they are called pages... The MMU can take  pages from anywhere in the Physical address space, and it puts them together into a virtual address space that the task sees as a single contiguous area of ram. This is why MP systems don't suffer from RAM fragmentation like the Amiga does. What you are suggesting is a serious amount of house keeping... MP is expensive enough in terms of RAM and CPU Cycles... in order to rebuild the virtual address space would require probably another 4gig on top of your exisitng ram!!!

You really do need to read about MMU's I suggest the x86 MMU as it is the most logical IMHO... I would be more than happy to help answer any questions!

Karlos wrote:
A single allocation of memory on a VM system using an MMU that an application uses a single pointer to refer to can translate into many unrelated chunks of genuine physical memory. You can't assume contiguous address mapped memory is contiguous in physical RAM.

Give me an example of when you'd use a pointer to address more than one memory location so I can explain how its done.

In MP system a contiguous block of Virtual memory is more than one Physical memory location. :-)

[bloodline]

HenryCase wrote:

HenryCase wrote:
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.

Continuing from where I left off...

Thought of an analogy about API calls that may be useful. In a restaurant, think of the API calls as the customers and the memory management and kernel as the waiter and chef. The customer can make any number of rediculous requests about what they'd like to eat, but in a restaurant it's the chef and waiter that decides what they're having. A non memory protected OS is like a restuarant without a waiter, the customers have to go into the kitchen to get their food, and can make a mess. If you put the waiter as a barrier between the kitchen and the customers then they can't make a mess in the kitchen. Hmm, must have food on the brain!

The point is API calls are not in control of the system, they are only means to make requests to that system. As long as the waiter delivers the same food that the chef was providing before the customer is not going to complain. Capiche?

Let me set a challenge. I've hopefully explained a little about how this memory abstraction layer will work. I'm going to stop calling it a MMU now and call it a MAU (Memory Allocation Unit) because although I am confident my ideas will work I don't know if this is how MMU's traditionally work.

My challenge is this. I have a program running which has got an important string "ABCDEF" stored in memory at real location "0x001" and virtual location "0x0FF". Using your knowledge of the Amiga's API architecture, I want you to try and corrupt this data. I am confident that whatever you suggest can be dealt with without breaking AmigaOS compatibility, so try and prove me wrong.

Task A Stores "ABCDEF" at 0x0FF.
Task A sends a message to Task B.
The message simply contains 0x0FF.
Task B looks at Address 0x0FF and it doesn't find "ABCDEF".

Reason:
0x0FF are two different Physical memory locations to the separate tasks. infact Task B might even have some code at its 0x0FF, or anthing!!!

The OS has no idea that Physical address 0x0001 has to be mapped to the same place in both tasks... in fact it might not even be possible to map that physical address to the same virtual address!

Neither of the Tasks can ever know the Physical address, as their 0x0001 is mapped somewhere else... different for each task!!!

[bloodline]

AJCopland wrote:

HenryCase wrote:

AJCopland wrote:
Wow you can do that? (note: this is sarcasm)

Think of it like HD defragmentation if it helps you understand it.

Oh I understand what you're saying perfectly clearly. An old version of an arcade game conversion that I worked on used a shared pool of memory instead of doing full blown networking (don't 'cos I can't tell you which). Each machine was given a physical ID (using jumpers) and this told them what address they were allowed to write into, and conversely what addresses other machines on the "network" would be writing into.

This situation is similar to the AmigaOS how? You ask. Well with AOS you've got a linear address space. Which means that to program#1 a pointer with the address 0x0000FEED is the same as program#2s address of 0x0000FEED.

Now at this point my knowledge of workbench/AOS gets wonky 'cos i've never done any coding in it.

The above means that programs could, and probably did, pass around the pointer addresses to data rather than actual data itself because since nothing ever set or respected the memory protection flags it was more efficient to pass a 4byte memory address than a larger data structure like a string.

Implementing memory protection or memory management et al at this stage would break all of those existing programs, and probably workbench as well because they'd no longer be able to communicate with either the underlying OS or the other programs like they used too as each program would be within its own 4GB protected memory space and so the pointer addresses that it was merrily passing around would no longer match those of the program on the recieving end.

EDIT: The relevence to the first paragraph i wrote is that if those arcade machines OS had memory protection then they'd never get each others messages because whilst they'd all be accessing their _own_ versions of the correct memory addresses the physical section of memory that they'd be writing too would be different from the physical address that the other machines were reading from :EDIT

Now that might all be bollox because i've had a long day.

You are spot on. This is exactly the situation we are in with AmigaOS.

I also just realised that this was the ColdFIRE thread and I only came in here in the hope that someone would be commenting on THAT topic. So I apologise profusely to everyone for continuing this off-topic subject.

Andy

This is sort of related :-)

[bloodline]

Hans_ wrote:

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.

If you have a flat VM... then you only have a single page table and you can't do per task protection!! Sure some pages can be read only... but really the only thing protected in that scheme would be the OS/Kernel... and that would give you a situation like Win95... shudder...

-Edit- Also, it would very hard to implement a VM paging to disk system with a flat address space... we all want  to be able to page memory to and from disk :-)

-Edit2- No, wait I see what you mean now! Separate spaces mapped to the same physical locations... yes that's doable, but the house keeping would be quite complex :-)

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

This is very true. As apple did!!! Sandbox out the old apps.

[bloodline]

HenryCase wrote:

AJCopland wrote:
Wow you can do that? (note: this is sarcasm)

Think of it like HD defragmentation if it helps you understand it.

If you understand HD fragmentation... then you can apply that to how the MMU works... which is basically the hardware that allows the memory fragments (or pages) to be addressed as though they were ordinary RAM.

AJCopland wrote:
With all due respect Henry both bloodline and karlos are trying to explain how MMUs work from a position of knowing, at least from a code point-of-view, how they function. So some of your replies have read as being rather rude.

I'm not trying to be rude, but it's hard to maintain composure when you are being misunderstood. As I've just mentioned, lets call my idea an MAU (Memory Allocation Unit) as apposed to a MMU as I don't know if what I'm describing is your daddy's memory management system, if you catch my drift.

The problem is that the OS doesn't  and can't know the mind of the programmer... The Programmer, on AmigaOS, is free to do whatever he/she wants. Thus the OS can't control what the tasks do, and they can happily break all the rules (The Memory protection) that you might want to put into place, and they suffer no ill in AmigaOS... but enforce those rules and the tasks break.

[bloodline]

AJCopland wrote:

With all due respect Henry both bloodline and karlos are trying to explain how MMUs work from a position of knowing, at least from a code point-of-view, how they function. So some of your replies have read as being rather rude.

Andy

Henry is just passionate, I can understand that! If I can help steer his passion then I am happy to answer his questions!

OS Design is not an easy topic, it's good that he wants to think about it and does think about it!

If he is getting frustrated, then I blame my inability to explain the situation... I will endeavour to improve my communication skills!

-Edit- I think we can also blame the AmigaOS designers for cutting corners :-D

[bloodline]

HenryCase wrote:

Kronos wrote:
@HenryCase

Problem is the OS can't decide wether one task made a legitemate request for data owned by another (lets say stuff running inside the input.device-task) or if it is just some roque pointer .....

I am not asking it to. I am asking the OS to make some limits on the commands that are physically not possible, like trying to put a 6-bit instruction into a 3-bit space. It was just one example of how the memory layer would keep the system stable.

But the OS can't limit anything, because it has no idea what the Tasks are passing to each other, or what they are accessing in the system...

Kronos wrote:
Next idea is usually to just copy system-structures into each tasks private part of memory, but once you take a look into the interlinked (and open) system-structures you'll notice that ain't pratical either.

Please expand on that point so I can understand it.

On a system like MacOX, to alter a system structure you have to use a specific OS function, this means that Apple can mess around with how the OS works and the Tasks are none the wiser... In AmigaOS due to it's open nature, tasks tended to alter system structures directly, which means the Amiga design team couldn't alter the system under hood... it also means they couldn't protect the OS anymore... as soon as you protect the OS, the tasks can't access the data they are used to accessing. Intuition, for example, actually documents this as an official method of working!!!! Apple would never allow anything like that!!!!

[bloodline]

Hans_ wrote:

bloodline wrote:

On a system like MacOX, to alter a system structure you have to use a specific OS function, this means that Apple can mess around with how the OS works and the Tasks are none the wiser... In AmigaOS due to it's open nature, tasks tended to alter system structures directly, which means the Amiga design team couldn't alter the system under hood... it also means they couldn't protect the OS anymore... as soon as you protect the OS, the tasks can't access the data they are used to accessing. Intuition, for example, actually documents this as an official method of working!!!! Apple would never allow anything like that!!!!

Way back when PowerPC cards were just coming out, programming guidelines were published that explicitly said something along the lines of:

In future OS structures will not be directly accessible. Use OS functions to access OS structures/data or your code will break in future versions of the OS.

The problem was, they never got round to providing all the accessor functions required.

Hans

By the time the PPC cards were coming out, the OS had been out of development for 3 years... I think providing the accessor functions or not... that was far too little much much too late :-) Commodore cut corners with AmigaOS from the very beginning... to meet deadlines or keep performance up I don't know... but AOS2.0 really should have fixed an awful lot more than it did!

[bloodline]

@HenryCase

I think you'd probably find "Managed Code" operating systems rather interesting the most famous being MicroSoft's Singularity!

These put such controls on the programmer that no memory protection hardware is needed, this offers some advantages of AmigaOS without the fragile nature of AmigaOS's open memory model! Obviously it has disadvantages too... But still, some of the ideas are likely to make it into the mainstream!

[bloodline]

AeroMan wrote:
I've never programmed a processor or microcontroller with MMU (unless you count PC code here, but I can't touch it), so let me ask to the MMU gurus here if my way of thinking is correct:

1: I suppose a task/process must be launched by the user or by the system at first instance.

2: The launched task may launch other daughter tasks if it needs.

Now the questions:

1: Am I wrong to suppose that the memory areas, will be shared only between the initial task, the system and the daughters ?

Depends upon the OS, Windows threads exist very much in the Parent's address space... I think the same is true of Linux, though I'm sure they are more heavy weight than Windows threads.

On these two OSs I believe only threads share address space, programs don't, and they MUST communicate via carefully defined and controlled methods.

2: If so, why would somebody share memory with alien tasks for other purposes than snooping ?

AmigaOS doesn't have threads... everything is a task, if you added Memory Protection these tasks should not share address space... You would need to add threading library really (AROS has added some fields to the task structure to make them pthread compatible*) :-)  

*I would note that new functions would need to be added to exec or a new thread library to make use of them!

3: How often would software do this ? One per cent ? Ten ? One in a milllion ? :-)

We use Tasks as an example because it's easy to see what's going on... but all the arguments apply to Libraries, devices and in fact all system structures... The scale of the problem is huge!

Tasks and libraries are always poking around in structures they don't own.

4: Could we protect the memory in such a way that the task could only see what was allocated by itself and it's sub tasks ?

As stated above, that is only a tiny part of the problem.

   This could work in a way like having the Amiga/AROS just for this task, and could avoid thrashing other tasks' memory.
   It looks fine for me, as it would ensure that a runaway task woud not mess with others.
 

Memory Protection will break so much you wouldn't believe it! Blame Commodore :-)

[bloodline]

-Edit- @HenryCase I would be delighted to discuss these ideas with you, but as others have suggested please start a new thread, so we don't upset anyone :-)

Reply here:
http://www.amiga.org/forums/showthread.php?t=35580

HenryCase wrote:
@thread

First of all, I'd like to thank those that have responded to my memory protection posts, I've got a lot to digest there, and will do ASAP. However, it is late so I'll concentrate on bloodline's post quoted below, as it seems the most concise.

Actually, I think AJCopland's games console story is probably the easiest to understand...

I would also like to state that I think memory protection would be useful with Coldfire, especially if we want to move away from emulating every 68k instruction.

@bloodline

bloodline wrote:

HenryCase wrote:
My challenge is this. I have a program running which has got an important string "ABCDEF" stored in memory at real location "0x001" and virtual location "0x0FF". Using your knowledge of the Amiga's API architecture, I want you to try and corrupt this data. I am confident that whatever you suggest can be dealt with without breaking AmigaOS compatibility, so try and prove me wrong.

Task A Stores "ABCDEF" at 0x0FF.
Task A sends a message to Task B.
The message simply contains 0x0FF.
Task B looks at Address 0x0FF and it doesn't find "ABCDEF".

Reason:
0x0FF are two different Physical memory locations to the separate tasks. in fact Task B might even have some code at its 0x0FF, or anything!!!

The OS has no idea that Physical address 0x0001 has to be mapped to the same place in both tasks... in fact it might not even be possible to map that physical address to the same virtual address!

Neither of the Tasks can ever know the Physical address, as their 0x0001 is mapped somewhere else... different for each task!!!

So if I understand correctly you're saying that the data cannot be read by more than one task because the OS doesn't know how to share this information?

No, The OS can easily put in place measures to share data... Due to the design of AmigaOS, the OS cannot know what data needs to be shared. The systems put in place to provide this information at Exec's design phase were never enforced, and thus ignored... Not only by Developers but by the OS design team themselves!

If I have understood correctly, allow me to use your example  but fix it with the MAU (yes I am still going to use that term to avoid confusion):

The problem is CPU's don't come with MAUs... they come with MMUs :-(

Task A requests to store "ABCDEF", the MAU stores it at location 0x0001 and passes back a pointer to that location through assigning a 'virtual memory space' 0x0FF.

But what is an MAU? Is it a piece of hardware? If so how on earth does it work? Where do we get one from?

Is it a piece of software? If so, are you really suggesting that we trap every single memory access made by a program on the off chance that something written to memory might be need to be shared? This would be so slow as to make the whole system pointless.

Task A sends a message through the MAU to Task B to look at memory space 0x0FF.
Task B makes the request to look at address 0x0FF, the MAU does not see a reason to not show this information, and fetches the string "ABCDEF" to pass on to Task B.

I have pointed out, as far as Task B is concerned 0x0FF does not relate to the same memory as What Task A sees as 0x0FF. Each task has it's own Address space... With Memory protection, each task effectively has its own computer... It has its own OS, it's own CPU and it's own memory, no other tasks exist in its universe... that is why memory protection is so safe.

Think of the Address space as being an island (imagine that the island is divided into 9 equal squares, this gives us a good 3x3 mental image, like a noughts and crosses board), and the Task as a small man living on that island.  

The tasks can talk by sending messages... message in a bottle if you like!

In AmigaOS, Both Tasks (little men) live on the same Island, if Task A puts something in square one, then Task B can find that data in square one, since Square one is the same for both tasks.

With Memory Protection:
Each Task (little man), lives in it's own address space (on it's own little island). When Task A puts something in Square one on it's own island, that data doesn't magically appear in square one on Task B's island... In fact Task B probably has something different in square one! Neither Task can ever know the layout of each other's island.

The reason for this is the way AmigaOS is designed... In operating systems that have had Memory Protection from the start, the developers have had to make sure that data that needs to be shared is done so via Operating system mandated method. In AmigaOS this was never necessary, and thus Tasks do not provide the OS with the information it needs to allow memory to be shared.

So in terms of memory usage, what do you have? You have one location where the string is stored in memory, a simple look up table stored in memory that is controlled by the MAU, the MAU itself which provides this abstraction layer and offers opportunities to control memory usage, and the memory spaces used by the tasks.

What you are suggesting is a look up table that records every memory access on the off chance that it might need to be shared... Which is massively resource heavy undertaking... both CPU cycles and Memory... and even then HOW does the OS actually know that when Task B is referring to a particual memory location that it needs to be shared with another task? The tasks are no required by AmigaOS to let anyone know what they are up to!

What you are failing to see is that you can second guess what's going on because you know all sides of the equation... Task A and Task B only care about each other and expect to be able to mess around with each other's data structures. And the operating system (with memory protection) only cares about keeping tasks from messing around with each other's data structures.

With the design of AmigaOS there has never been the need to let the OS know that it's OK for task A to interfere with Task B... Thus no software has ever provided the OS with the information it needs to allow the tasks to Share Memory, in a Memory Protected environment.

The address 0x0FF can be called as many times as you want (please note this virtual memory value can only be assigned to one real memory space at a time), but each time the MAU will make a decision based on certain rules to determine whether that access is given.

But this is just it, programs written for AmigaOS do not provide enough information to the OS/MMU/MAU to allow it to make a decision as to what is shared and what is private.

It will also be giving programs non overlapping memory spaces to run in.

Does this explanation help?

EDIT: Should also say that I intend to separate kernel commands from the kernel itself so that its commands go through the MAU too (obviously with a high level of privileges). I thought that was worth pointing out in case you thought I was intending to do MP with the standard design Amiga kernel.

It's easy to design an OS with Memory Protection, there are numerous examples... what we have with AmigaOS is a system that has a 25 year development legacy of no Memory Protection, All existing programs assume this to be the case. You add memory protection and you have put them into a new environment that is no longer AmigaOS and they won't run.

[bloodline]

shoggoth wrote:
In FreeMiNT (ok, I'm from the other side of the fence, sorry), it's possible to specify the level of protection for each process through dedicated flags in the program header. In practice, this means that you can flag two apps as belonging to "global" memory, causing them to share the same address space. These two applications can then access eachothers memory freely. (Ok, it's not considered perfectly clean, but it provides some degree of compatibility for older applications). Well behaved applications can run as "private", and their memory can't be touched nor can they touch other memory belonging to other processes.

Couldn't this approach be used in AmigaOS as well?

Reply in new thread!

http://www.amiga.org/forums/showthread.php?t=35580

[bloodline]

AeroMan wrote:
@ biggun

  Some posts ago, before the discussions about MP and related stuff, I´ve made a post asking about the feasibility to preview the use of many Coldfires connected together to speed up the things....
  The idea is to make it scalable, so it could go from a really small and cheap device up to a desktop with some software compatibility between then
  Do you think it is possible ? (please, check my post...)

I don't think Coldfire has support for Multiprocessing, so you'd have to build some complex arbitration hardware and software... Certainly AmigaOS doesn't support multiprocessor environments...