Overview Features Coding Performance Forum Downloads Products OrderV4 Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Information about the Apollo CPU and FPU.

"APOLLO SHIELD" Memory Protectionpage  1 2 

Gunnar von Boehn
(Apollo Team Member)
Posts 5474
23 Jun 2021 13:59


nick fellows wrote:

Why is this , where does it come from and can we stop comparing apples to horses?

I think you misunderstand this.
This is not about slanting and putting Linux down.
We not need to slant Linux, as we all know Amiga OS is much better ;-)

The goal with this post was explain people why the Linux way of memory protection by design not works on Amiga.
And that one of the fundamental virtues of Amiga OS are against it.



Nick Fellows

Posts 111
23 Jun 2021 14:15


I cant argue with that, reason linux is my daily driver is because it felt more amiga like than windows which was like a downgrade about 30yrs ago. I've always looked to continue that experience.

To make the vampire a success we need to be open to interoperability and we need the tools to make development a breeze lets be more welcoming to new ideas etc.


Gunnar von Boehn
(Apollo Team Member)
Posts 5474
23 Jun 2021 14:48


nick fellows wrote:

we need the tools to make development a breeze lets be more welcoming to new ideas etc.

 
Exactly I full agree.
Actually APOLLO-SHIELD is a tool to help developers.
 



Manfred Bergmann

Posts 211
23 Jun 2021 17:50


Gunnar von Boehn wrote:

Kamelito Loveless wrote:

  I guess you need some kind of resources tracking to be able to know when an app poke  into another app memory right?
 

 
  AmigaOs is designed for other apps to write and work in other apps memory.
 
  You can imagine this like the postman coming to your ground and putting a letter in your letterbox.
  Or the pizza boy coming bringing you a pizza.
  Or the cleaning woman coming and cleaning your kitchen.
  All this are normal operations on AmigaOS.
  And other programs visiting your "house" is always allowed and wanted.
 
 
  This is totally different to Linux.
  On Linux no other program can visit any other programs house.
  And even very simple task like delivering letters or a pizza ares super complicated and super slow on Linux.
 
 
  On AmigaOS "visits" are always allowed and are welcome.
  The only option on AmigaOS to "catch" bad programs is by placing minefields in the "empty" spaces ... and waiting for a rouge program to run in your minefields.
 

This view is of course bending the truth.

All the examples you mention are of course possible on Linux or on any other OS. The difference is that there the program has control over if the postman can come onto my property and how that happens and can setup interfaces and protocols to do that. The OS merely provides the required infrastructure.
On Amiga there is no enforced protocol. Just everything is possible. Coming back to your examples then it's like: "the bad postman just goes into your house undetected and steals your LP collection".

The difference is just the level of trust.
On Amiga it's a trust-all. There are only good programs doing only good things.
On Linux it's 0-trust.

Neither of this is wrong or right. It just depends on what is it going to be used for. Clearly Linux can't do the things Amiga can. But also Amiga can't do the things Linux can.



Gunnar von Boehn
(Apollo Team Member)
Posts 5474
23 Jun 2021 19:11


Manfred Bergmann wrote:

This view is of course bending the truth.

 
Actually I found it was a very nice and easy to understand picture.
 
But maybe you find another one?
 
The truth is AmigaOS allows direct HW access and allows fast and direct programming. While Linux does not. And Stuff which is light and simple to do on Amiga OS is slow and complex on Linux.
 
Lets make a real example:
 
What do you need to do to test the mouse button?
Just one ASM instructions is enough on Amiga:
BTST #6,$BFE001
 
How many instructions do you need on Linux?
100? 1000?
Maybe you can fill in the answer for this.
 


Manfred Bergmann

Posts 211
24 Jun 2021 07:27


Gunnar von Boehn wrote:

Manfred Bergmann wrote:

  This view is of course bending the truth.
 

 
  Actually I found it was a very nice and easy to understand picture.
 
  But maybe you find another one?
 
  The truth is AmigaOS allows direct HW access and allows fast and direct programming. While Linux does not. And Stuff which is light and simple to do on Amiga OS is slow and complex on Linux.
 
  Lets make a real example:
 
  What do you need to do to test the mouse button?
  Just one ASM instructions is enough on Amiga:
  BTST #6,$BFE001
 
  How many instructions do you need on Linux?
  100? 1000?
  Maybe you can fill in the answer for this.
 

It seems a nice picture. But the pictures are insofar inaccurate as those actions of the postman and the pizza man are bound to a protocol. In reality the postman can't just go into your house or your back garden, neither can the pizza man. There is a protocol that defines what he is allowed to do and where he can put the delivery if you're not at home. The pizza man has to go to your door and ring the bell. That is backed either by law, and/or by regulations of the post or pizza service.
But on AmigaOS there are no protocols, no law and no regulations other than the ones you put on yourself.

How many assembler instructions are necessary on Amiga for a mouse click is not relevant for Linux at all. Because that is not something Linux will ever need.
So I think both should not be compared.
Live and let live.



Gunnar von Boehn
(Apollo Team Member)
Posts 5474
24 Jun 2021 08:49


Manfred Bergmann wrote:

How many assembler instructions are necessary on Amiga for a mouse click is not relevant for Linux at all.

 
I seem to again misunderstand the point here.
 
The point is that Amiga OS has some virtues which in my opinion are great.
Amiga OS has a very lightweight design.
Amiga OS allows all programs to have direct hardware access.
Amiga OS allows to coder to have full control.
 
The combination of this results in some things we all love about Amiga.
  - Coding on it is a lot fun.
  - Amiga programs are very fast and very slim.
  - You as coder have a degree of freedom and control that you have not on other systems.
 
What we try to explain is that these virtues come as a design decision. And this design decision does rule out memory protection.
 
And if you would try to "add" memory protection in the Linux sense then this would break the virtues of Amiga OS.
 
If you coded on Amiga and or Linux then you know this.
Coding on Amiga and on Linux is as different as riding a Harley Motorbike and driving a family car. Very different feeling. 

The point is you can not mix both.
If you try to add 4 more wheels to the Harley.
And a truck full of kids.
Then this will destroy the Harley feeling.




Bert Smith

Posts 3
25 Jun 2021 05:39


nick fellows wrote:

Why did you feel the need to compare to Linux ? When you could have used Windows or Mac OS? when you said :
 
  "This is totally different to Linux.
  On Linux no other program can visit any other programs house.
  And even very simple task like delivering letters or a pizza ares super complicated and super slow on Linux."
 
  Heres some facts
 
  AmigaOS uses a microkernel architecture which lends itself to small, compact efficient "Real Time Operating System" RTOS
  This is what you mean when you talk about speed and efficiency.
 
  All 3 of the alternative mainstream operating systems use a
  monolithic kernel design yet for some reason you single out the open source one.
 
 
  Im a long time supporter of Vampire , i own a V1200 card which im yet to set up. While this is a forum for Vamped Amigas so one would expect a bias here; i see no slating of other operating systems excpet a clear and present bias against Linux. It troubles me because i was planning on trying to port some linux programs to vampire.
 
  Im feeling hostility towards doing this before i have even started.
 
  Why is this , where does it come from and can we stop comparing apples to horses?
 
 

Linux and Windows are monolithic kernels because monolithic kernels actually perform better and have less overhead than microkernels.
AmigaOS is in many ways actually more monolithic, because there is no real kernel/userland separation, and this is where it gets its performance.

Linux and Windows are designed to separate kernel (including hardware drivers and system services like the networking stack etc) from userland programs (ie applications run by the user). This provides security and protection against buggy userland programs from crashing the system, but comes at the expense of extra overhead. For multi user systems this separation is essential as it prevents users from interfering with each other, and it also means that a buggy userland application cannot crash the whole system because userland applications and the kernel are sandboxed from each other. It doesn't protect against buggy kernel drivers, which can easily crash the system.

Microkernel systems like Mach and GNU Hurd take this a step further, and try to separate out more system services such as hardware drivers and the networking stack etc. The goal being that bugs or security flaws in these services are sandboxed and can't affect the system as a whole, the drawback being that the increased separation comes with increased overheads.

Because of this separation, getting data between the different sandboxes requires a message passing system, data needs to be written into a shared area of memory and the other sandbox needs to be told how to access it, the processor needs to context switch between kernel and user space etc.

AmigaOS takes the opposite approach, everything runs in a single address space and has direct access to all the system resources, no sandboxing, no overhead. There is no message passing mechanism required, as different processes can simply read the data directly from wherever it is on the system. Effectively AmigaOS is the ultimate monolithic kernel, as absolutely everything runs in kernel mode.
This is why it's small and fast, but provides no security or protection against buggy programs crashing the whole system.

This is great for enthusiasts who want to tinker, learn about the system and exploit its full potential, its also great for teaching programmers to write stable code as they can't rely on the kernel to shield them from mistakes. But it's terrible for a multiuser server that has to process untrusted data from potentially malicious users.
Different strokes for different folks as they say.


Nick Fellows

Posts 111
25 Jun 2021 10:19


You say :
"AmigaOS is in many ways actually more monolithic, because there is no real kernel/userland separation, and this is where it gets its performance."

Peer Reviewed source says :

https://en.wikipedia.org/wiki/Kernel_(operating_system)#Amiga

"The Commodore Amiga was released in 1985, and was among the first and certainly most successful home computers to feature an advanced kernel architecture. The AmigaOS kernel's executive component, exec.library, uses a microkernel message-passing design, but there are other kernel components, like graphics.library, that have direct access to the hardware. There is no memory protection, and the kernel is almost always running in user mode. Only special actions are executed in kernel mode, and user-mode applications can ask the operating system to execute their code in kernel mode."


Gunnar von Boehn
(Apollo Team Member)
Posts 5474
25 Jun 2021 10:44


Lets not forget that this topic is about APOLLO-SHIELD.

Do you have question to it?

Do you like it?




Nick Fellows

Posts 111
25 Jun 2021 16:40


It seems like a good idea to me


Claudio Wieland

Posts 7
28 Jun 2021 09:22


Gunnar von Boehn wrote:

Lets not forget that this topic is about APOLLO-SHIELD.
 
  Do you have question to it?
 
  Do you like it?

Hello Gunnar, have you implemented a sort of MPU for this?


Gunnar von Boehn
(Apollo Team Member)
Posts 5474
28 Jun 2021 13:32


Claudio Wieland wrote:

Hello Gunnar, have you implemented a sort of MPU for this?

Hallo Claudio,

Yes, the Apollo 68080 CPU has an MPU and we just use it.


Claudio Wieland

Posts 7
28 Jun 2021 14:28


Great. Does the MPU catch all kinds of DMA accesses? Like blitter trying to overwrite code areas etc? Does the MPU save the DMA bus participant ID (like blitter, cpu, ..) for debugging ease?


Gunnar von Boehn
(Apollo Team Member)
Posts 5474
28 Jun 2021 16:39


Claudio Wieland wrote:

Great. Does the MPU catch all kinds of DMA accesses? Like blitter trying to overwrite code areas etc? Does the MPU save the DMA bus participant ID (like blitter, cpu, ..) for debugging ease?

The 68080 MPU support three types of rights.
1) right to Write
2) right to Read
3) right to Execute

Per default Apollo Shield will mark all illegal areas and will catch access to unused spaces and also catch if you write e.g in ROM space, or if the CPU tries to "jump" into IO space/ Chipset register.

Yes, and the MMU will also track DMA.
This means you can catch DMA going into illegal spaces.

Code space is per default not set to write protect.
So per default write or DMA write into code segments are not tracked. But in theory this could be set this way.



Tim Trepanier

Posts 117
28 Jun 2021 17:00


Gunnar von Boehn wrote:

  The 68080 MPU support three types of rights.

Can you verify that the MPU is part of the 68080 design and not part of the FPGA? Thanks


Gunnar von Boehn
(Apollo Team Member)
Posts 5474
28 Jun 2021 17:04


Tim Trepanier wrote:

Gunnar von Boehn wrote:

  The 68080 MPU support three types of rights.
 

 
  Can you verify that the MPU is part of the 68080 design and not part of the FPGA? Thanks

The MPU is part of the Apollo 68080 CPU, and the Apollo 68080 itself is placed inside the FPGA.




Claudio Wieland

Posts 7
28 Jun 2021 17:05


Gunnar von Boehn wrote:

Claudio Wieland wrote:

  Great. Does the MPU catch all kinds of DMA accesses? Like blitter trying to overwrite code areas etc? Does the MPU save the DMA bus participant ID (like blitter, cpu, ..) for debugging ease?
 

 
  The 68080 MPU support three types of rights.
  1) right to Write
  2) right to Read
  3) right to Execute
 
  Per default Apollo Shield will mark all illegal areas and will catch access to unused spaces and also catch if you write e.g in ROM space, or if the CPU tries to "jump" into IO space/ Chipset register.
 
  Yes, and the MMU will also track DMA.
  This means you can catch DMA going into illegal spaces.
 
  Code space is per default not set to write protect.
  So per default write or DMA write into code segments are not tracked. But in theory this could be set this way.
 

Thank you for the explanation. One question was unanswered, though :) . Can the programmer identify the hardware unit or bus participant that caused the access violation?


Gunnar von Boehn
(Apollo Team Member)
Posts 5474
28 Jun 2021 17:35


Claudio Wieland wrote:

  Thank you for the explanation. One question was unanswered, though :) . Can the programmer identify the hardware unit or bus participant that caused the access violation?

Tracked and reported are:
- PC of the offending instruction
- Address of the illegal access
- Type of the violation (read/write/execute/dma)

The DMA channel ID is not recorded today.
But adding this i a nice idea indeed. thanks


Claudio Wieland

Posts 7
28 Jun 2021 17:57


My pleasure. This would really help debugging, I think.

posts 40page  1 2