Memory protection support

5 posts / 0 new
Last post
walkero
walkero's picture
Offline
Last seen: 4 months 1 week ago
Joined: 2009-05-03 16:54
Memory protection support

For a long time now I think that the Hyperion programmers implemented the memory protection in the AmigaOS 4. I don't remember exactly since which version this exists. I also heard that this is temporary disabled and there no way to enable it, because a lot off programs won't work if this is enabled. Is this thing true?

In case it is true, should we already create our programs in a way to support this feature, so that when the time comes to enable it we won't have to change the code we written? Are there things that we should not use because they won't work with memory protection?

Thank you all or your help and time.

kas1e
kas1e's picture
Offline
Last seen: 3 months 3 weeks ago
Joined: 2010-11-30 15:30
As far as i know, they

As far as i know, they introduce protections of few parts, but from coding side i know only about one (sorry for lame explain) : when you just make in your programm "STATIC const something", or "STATIC blalblab", then all your arrays will be in some kind of "protected memory". And when any programm (include main one , with that array blocks), will try to write by this memory area, will crashes with GR on os4 (what mean that some kind of memory protection happens). On other oses (and that include mos/aros and of course os3), its all just happens in silence, and those areas not protected.

I can't remember right now, in which code-segment that static arrays are puts (.rodata, or something), but i remember that "readelf" and "objdump", do not show that this code segment are protected (while in reality is it, just those tools was not updated with os4 changes in that terms).

Related to what we can do to make our apps better, its all the time use STATIC consts stuff (to add some "protection" ), and MEMF_VIRTUAL for all the AllocMem (not MEMF_PRIVATE or MEMF_SHARED). With MEMF_VIRTUAL, memory can be swapped, so its some sort of protection as well.

Will be intersting to discuss all of this (and maybe make an article which cover all what we have in terms of MP from coder's point of view).

Belxjander
Belxjander's picture
Offline
Last seen: 8 years 11 months ago
Joined: 2011-02-25 11:53
I would highly recommend

I would highly recommend *all* allocations to be virtual and only to declare differently
for any allocations that are specifically to be shared between processes.

I would personally mark the entire of memory as read-only and permit writes only into allocated
areas forcing any Application that is not conform to have an immediate ISI/DSI Reaper Request.

Just my own thoughts on the matter :)

Rigo
Rigo's picture
Offline
Last seen: 2 years 6 months ago
Joined: 2011-01-24 21:55
Not memory protection as

Not memory protection as such, but resource tracking is supplied courtesy of AllocSysObject and AllocDosObject.

These functions will track the allocations, and free them when the process is removed. This is to be regarded as a safety net though, do NOT rely on this functionality. This is purely implemented to try and assist the more errant programs out there, but there is no replacement for correct coding style. basically deallocate everything you allocate, but the tracking system is there, even if in small parts so far.

Simon

TSK
TSK's picture
Offline
Last seen: 1 year 2 months ago
Joined: 2011-06-28 02:06
Edit: Nevermind my question.

Edit:

Nevermind my question. I found an answer from the support forum of Hyperion.

Log in or register to post comments