jdp@caleb.UUCP (Jim Pritchett) (03/07/90)
[]
I have an idea for memory protection for the Amiga OS. Step 1: assume
MMU. Step 2: all memory shared between multiple processes (i.e. OS
stuff, messages, etc.) can only be written by an OS server process.
When a user level process wants to write to shared memory, it asks
the OS server to do so. Any errant process trying to scribble outside
of its area would cause the MMU to generate an error. Is this reasonable?
Basically, let anyone read anywhere they want (i.e. in the specially
mapped shared area), but the MMU is used to prevent any user task from
writing there. This would be slower than now (MMU waits + server time)
but I think that it could be made to work.
Before you flame me, please remember that I am NOT an expert here. This
is basically just a response to all the "memory protection is impossible
with the Amiga OS" posts. I am curious as to why this would not be
feasible. (Of course, I am suggesting a very major change to the OS
here.)
--
Jim Pritchett
UUCP: {attctc|texbell}!letni!dms3b1!caleb!jdp
or texbell!rwsys!caleb!jdpes1@cunixb.cc.columbia.edu (Ethan Solomita) (03/09/90)
In article <7955.AA7955@caleb> jdp@caleb.UUCP (Jim Pritchett) writes: >[] > >I have an idea for memory protection for the Amiga OS. Step 1: assume >MMU. Step 2: all memory shared between multiple processes (i.e. OS >stuff, messages, etc.) can only be written by an OS server process. >When a user level process wants to write to shared memory, it asks >the OS server to do so. Any errant process trying to scribble outside >of its area would cause the MMU to generate an error. Is this reasonable? >Basically, let anyone read anywhere they want (i.e. in the specially >mapped shared area), but the MMU is used to prevent any user task from >writing there. This would be slower than now (MMU waits + server time) >but I think that it could be made to work. > >Before you flame me, please remember that I am NOT an expert here. This >is basically just a response to all the "memory protection is impossible >with the Amiga OS" posts. I am curious as to why this would not be >feasible. (Of course, I am suggesting a very major change to the OS >here.) > The problem with that is that so many programs write to other space intentionally, especially with interprocess communications. For the gurus out there, how would this sound: Have all programs default to as above, unable to write to other areas. However, there is a library command that disables that as necessary. Also, a program which is considered bug-free can shut it off for the speed increase. Perhaps we would even see it show up in a program's preferences! -- Ethan Ethan Solomita: es1@cunixb.cc.columbia.edu Compu$erve : 70137,3271 Anyone giving away Amigas or Sharp Scanners???
cg@ami-cg.UUCP (Chris Gray) (08/10/90)
In article <13694@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: > > As an intermediate step to full memory protection, why not just forbid read > > and write access to free memory? This won't do a thing to stop programs > > from corrupting each other, but it might help catch the bugs that cause > > these problems. > > As I said in my previous message, this has just been done. And indeed a very > large amount of software is caught in the act thanks to this utility. Often > people on the net feel that their suggestions go unnoticed. I hope the > Guardian-Angel proves that to be false. Keep them coming. Great! I love it. I have an A2000 + A2620. Can I run such a beast or is it somehow tied to the 68030? Is it possible to get it? How about the other 'CPU' program I hear comes with the A3000 software release? God I hate articles like this - they sound so much like begging. -- -- Chris Gray usenet: {myrias.com,uunet.uu.net!myrias,alberta!myrias}!ami-cg!cg CIS: 74007,1165
valentin@cbmvax.commodore.com (Valentin Pepelea) (08/14/90)
In article <02722.AA02722@ami-cg.UUCP> cg@ami-cg.UUCP (Chris Gray) writes: >> >> Often people on the net feel that their suggestions go unnoticed. I hope the >> Guardian-Angel proves that to be false. Keep them coming. > > Great! I love it. I have an A2000 + A2620. Can I run such a beast or is it > somehow tied to the 68030? Is it possible to get it? How about the other > 'CPU' program I hear comes with the A3000 software release? Yes, your Guardian-Angel will follow you even into an A2620. I don't know what the availability of this tool will be. As to the A3000 software release, the TRAP option of the c:cpu command is now obsolete. Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
brett@smosjc.UUCP (Brett Coon) (01/08/91)
In article <17134@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >In article <1991Jan5.200226.19718@msuinfo.cl.msu.edu> dailey@frith.uucp (Chris Dailey) writes: >>Even fake memory protection would due for many of us. How about a >>command like "run such and such a program so it doesn't touch anything >>other than the OS". It gets its own space, tucked away from the rest of >>the system? > > The problem is defining "it's own space". What is part of the OS, >and what is part of an App? What if an "application" (let's say Mount) >allocates a data structure and adds it to a system list? One thought I had for a sort of compromise is a PD library of MMU routines that programs could use to protect themselves, especially during the devel- opment stage, but optionally as commercial products as well. The MMU library would provide replacements or patches for various AmigaDOS calls to allow programs to specifically decide what areas of memory they have access to as well as what areas of their memory they want to protect. Programs that are written without the MMU libraries would function normally, with full permission to trash one another's memory. This would be considerably easier to implement than "real" memory protection, since applications that use the MMU functions could be considered trustworthy. Its purpose would be to provide a reliable means to debug programs and prevent or contain crashes. If the library defaulted to standard non-MMU system calls on machines that don't have an MMU, developers would have to reason to remove the code once development finishes, so eventually there would be many programs available with MMU support. Of course, this would still be a substantial project, but I think the benefits would be great. -brett -- |Brett Coon | uunet!smosjc!brett | |S-MOS Systems, Inc. | "Very exciting... as a luggage problem." | |San Jose, CA | -Joe Vs. The Volcano |