NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/amiga/programm/15882

Internet Message Format | 1992-11-15 | 2.8 KB

Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!decwrl!hal.com!darkstar.UCSC.EDU!cats.ucsc.edu!davids
From: [e-mail] (Dave Schreiber)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: physical memory protection with MMU
Date: 16 Nov 1992 03:37:53 GMT
Organization: University of California; Santa Cruz
Lines: 45
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
NNTP-Posting-Host: as215-ws-17.ucsc.edu


In article <[e-mail]> [e-mail] (Paul Kienitz) writes:
[Somewhere, I wrote:]
>> The real problem with memory protection on the Amiga is that it is
>> possible for one task to share its memory with another without
>> explicitly telling the OS that the shared memory is in fact shared.
>> This is a big nono under a protected OS.  However, it is an
>> exaggeration to say that 99.9% of Amiga programs do this.
>
>Almost every program shares memory -- any time you do IO at either
>the dos or exec level, any time you listen to IDCMP events, or look
>at any system list, you're sharing memory between tasks.
>
>But of course, we ALWAYS remember to use MEMF_PUBLIC in those cases,
>right?

Intuition allocates the memory used in IDCMP messages.  If it doesn't use
MEMF_PUBLIC for that memory now, it will by the time Exec implements
protected memory.  In any case, it isn't an application issue.

Now, as for I/O, I'm assuming that you're referring to the buffer that
holds the data to be transferred.  In that case, what does the device
driver receive eventually?  A structure of a known length with a pointer
(in a known place in the structure) to a memory buffer that is also of a
known length.  In short, the device driver knows exactly what memory it
will need to access, so it should be possible to include an OS call that
would allow the driver to check to see if the memory it has received is
MEMF_PUBLIC.  If not, give the driver another call that will make it sharable.
This could blow system security out the window, of course, but for the
moment it seems that most people want memory protection to stop errant
programs, not malicious ones.

The real problem stems for two (or more) tasks that pass their own
privately defined structures around.  If a structure like that contains
a pointer to memory that needs to be declared shared, Exec will never know
and won't be able to pull off the protections-changing trick, and the
receiving program will generate a protection violation and be terminated.

As for system lists, make them (and the things they point to) publically
readable but not writable, or make them readable and writable after
the calling process performs the appropriate Lock*() call.


--
Dave Schreiber  "Look.  Don't touch."  [e-mail] (until 6/20/93)