@Intuitioned

Picture
It was 0xDEADBEEF actually. MungWall works by putting certain (non-zero) values at certain location f.ex. 0xABADCAFE at address 0, it also fills up unused memory, puts protection barriers around allocations and initialises memory not allocated with MEMF_CLEAR to force programs that use uninitialised or bad pointers into crashing.

@salass00

I agree with you that software should be robust and bug free. However, there is a saying (if not a law) something roughly like "You can prove the existance of bugs in a program but you can't prove that a program does not have any bugs.". It's sort of like saying that people shouldn't bother wearing safety equipment and be more careful instead.

The simple solution is not to run buggy software but one doesn't know it's buggy until it crashes the first time round. It might even be known as very stable, but your hardware could be slightly different to everybody else so it crashes, taking out your lengthy DVD processing or animation rendering that "was" running in the background. You might even have a virus that is slowly rewriting the OS.

_________________

Anyway I don't know how it works (except that it is something to do with the MMU) but would like it anyway.

_________________

@Intuitioned

Quote:

"You can prove the existance of bugs in a program but you can't prove that a program does not have any bugs."

That is correct, but with the right debugging tools you can find quite a lot of them. The ones I use for now when I want to debug something are: MuForce (mmu.library replacemtn for Enforcer), MuGuardianAngel (mmu.library replacement for MungWall plus a few other tools) and Sushi (redirects the serial output to the console handler device). I've been able to find and eliminate a lot of out of bounds memory accesses with the help of these programs.

Thinking a little ahead when coding can also help, not to mention solve a few head-aches later .
Quote:

It's sort of like saying that people shouldn't bother wearing safety equipment and be more careful instead.

The problem is these tools are only good for debugging they are in no way to be considered a solution for buggy programs! And if there's one thing I really hate about this it is that the user is punished for the programmers' sloppiness, by being forced to use CPU-cycles for something that is totally unnecessary in that it doesn't usually solve anything at all (as in the case of message-passing by copying memory ).
Quote:

You might even have a virus that is slowly rewriting the OS.

Well that should be quite easily taken care of by having less open OS structures. For one thing OS4 won't have the traditional jumptables (which were used a lot by viruses previously) other than for compatibility with pre-OS4 programs .

@olegil

Quote:

Remember the talk about orthogonal persistence? 64 bit addresses is in no way needed for CURRENT systems, but the things it makes possible changes the whole theory behing operating systems...

Larger than 32bit address is required for high performance desktop applications and server side applications e.g. MIS databases. Note that the PAE has been deemed to be inadequate. One example is the 32bit limitation is a certain +~4.2Ghz processor with a certain operating system i.e. displayed a wrap around value of 300Mhz.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@salass00

That is correct, but with the right debugging tools you can find quite a lot of them.

Sure, but how are you going to protect your program from somebody else buggy program that thrashes your program's memory space ?

_________________
~
Everything you say will be misquoted and used against you..
~

@olegil

Quote:

Protecting the internal structures of the OS: Also a good idea, but would break some programs.

Yes. That's why it will come gradually, not all at once.

Quote:

The question is, do we care? Yes, some users might want to run some obscure application that is inherently broken and does things it shouldn't be doing

That's the point. For some time, we'll still rely on old applications to do the job; therfore, we can't afford to change too much and lock them out.

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

@JCC

Quote:

How about protecting the system data structures for normal compliant programs and creating a special "wrapper" program only for pre-OS4 applications.

This would mean that new OS4 applications must adhere to the new rules at once, which might be inconvenient when porting stuff to the new platform. Too drastic changes will probably scare off a lot of people.

I think the best solution is to gradually go from the current situation to a new, more protected environment. It allows people to get used to the new methology.

When we start to tackle this, we intent to have devloper versions of the kernel that already implement the required protection so that developers can already test their software in the new environment.

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

@Georg

Quote:

Speaking about stack, how does AOS4 automatic stack enlarging code deal with evil cases like:

Not at all. There's a new API for allocating stacks that has to be used. If it's not used, the old methods of dealing with stacks is used, including StackSwap-ability. There's no way to make this work without the application being aware of it.

One thing will never work reliably: Manual stackpointer swapping. It works when done in a 68k part (because an emulator switch will correctly align the stackpointer and build a PPC stack frame), but it's dangerous.

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

@salass00

Quote:

I have to say I disagree with you here. Real stability should come from robust bugfree software not be added as some kind of afterthought. It just doesn't work that way.

How do you write such software in the first place ? You have to detect this.... Of course, the software should not do any nonsense, but a protected environment will be your last line of defence.

I've been told multiple times by people critizing memory protection (anybody remember the old Amiga Open list discussion about MP in Intent ?) that memory protection is an excuse for lazy programmers. This is absolute nonsense. NOT having memory protection is an excuse for lazy programmers. Because they get away with their nonsense in an unprotected environment. If it's protected, they wont, because every illegal access terminates the program...

Additionally, memory protection is not only about shielding you from stupidity of programmers. It's also to protect you from malicious code. Imagine an encrptyion service running in shared memory: Everybody can see what's going on there...

Quote:

I would guess it's about the same as with Enforcer/ MuForce and MungWall under OS3.x, only Grim Reaper has a fancy GUI. AFAIR one of the Grim Reaper screenshots had 0xDEADF00D (I think that was the one) as the contents of a register, which is a sign of MungWall.

It's not MungWall inthis case, but the program that was used to create the crash just wrote something to 0xdeadbeef.

But yes, currently, it's about the same functionality as Enforcer. Additionally, some pieces of the memory are protected against illegal access, for example, the MMU table itself is write protected in user mode. This is mainly though as a guard against accidential overwriting.

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

@EntilZha
Quote:

One thing will never work reliably: Manual stackpointer swapping.

So no (set|long)jmp() then? No user-level threading libraries? No exception handling with c++, java and the like? Somehow I think I'm missing something.

_________________
“It is well enough that people of the nation do not understand our banking and monetary
system, for if they did, I believe there would be a revolution before tomorrow morning.”
~~ Henry Ford

@falemagn

Quote:

So no (set|long)jmp() then? No user-level threading libraries? No exception handling with c++, java and the like? .

Sorry, I was inexact: Of course, every program already manually sets the stackpointer by just advancing it to build a new stack frame.

What I was referring to was the case where a program just sets the stack pointer by itself without knowing what it does. On the PPC, there's nothing like the 68k's push operation where you just push values to the stack and decrese the stackpointer. It has to follow some rules, i.e. build a stack frame by advancing the stack pointer, setting up a proper backchain, and then store registers to the designated register save area. This means that you have to *know* about the stack layout. Blindly using the stack pointer doesn't work, and never did, even on the 68k.

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

@EntilZha

If I came off as 100% against MP that's not what I meant (a few years ago that might have been my opinion though). The point I try to make is that this should be entirely optional, be for debugging purposes only (or at least foremost) and most importantly not come at the price of performance for the average user (f.ex. msg-passing by copying).