@ksk
The memory used by other apps/OS is *allocated*, thus the hit will not be detected. Apps/OS will crash.
It does not change anything!
Oh yes it does. The apps/OS will crash. Prove me wrong instead of yelling "It does not change anything!".
The propability of OS detecting misbehaving application becomes better when it detects access to unused memory (perhaps before it hits some used memory).
This is true, however very rare. Only very large hits will be detected, and usually it is already too late then (freelist or other allocated memory is trashed).
MMU pagesize is 4096 bytes, minimum. This is the granularity the memory protection can be set. As long as MMU page has any used memory, it cannot be made write protected (or invalid, if using new memory system that separates free memory and freelist).
What is the typical free memory hit? 99% of the time it's buffer overflow. The application will overwrite memory past the allocated area. Unless if the end of the allocated memory chunk is exactly at the MMU page border (aligned by 4096), the hit will go 100% unnoticed by MMU, and free list or other allocated memory will be trashed.
Other typical case is memory allocated by the application (or someone else) that is then freed but your app still accesses it. Catching these will ONLY work if the whole MMU page worth of memory is made unallocated. If any of the memory within the MMU page is still in use, the MMU page cannot be marked write protected (or invalid). Most of the time the hit will go 100% unnoticed again, and it's too late. You've already trashed other allocated memory or freelist.
(uninitialized pointer is not the only case, accidental use of freed memory seem to happen often in OO code)
Catching these will only work if the freed block is very large and the accessed are hits MMU page that is all free. Quite unusual, since typically the access happens to beginning or end of the block, which are unlikely to be all free memory.
(and AOS is not the only OS using that kind of partial MP methode, I know a few million of users elsewhere for that kind of memory protection system (also using some other tricks))
Really? I haven't heard of such systems. Care to list some?
It's just better than not having any protection at all.
If the protection has a performance penalty, it doesn't really give protection, *and* it gives programmers false sense of security... I am not sure if it's good.
Just take a look at some of the sloppy coding practices used in "protected" environments.. No checking of allocated resources, they rather crash and let the system clean up the resources than catching the condition themselves. I am not claiming such programming practices will automatically be adopted because of this, but is it more likely? IMHO yes.
I rather would see true memory protection than such limited hack that has little to nothing to do with Memory Protection.
What I would like to see most, however, is adoption of proper and good programming practices. But that is not going to happen.
