From: andy@cbmvax.commodore.com (Andy Finkel)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: Future Amiga chipsets
Date: 28 Dec 92 14:47:24 GMT
Reply-To: andy@cbmvax.commodore.com (Andy Finkel)
Organization: Flying Cat, Inc.

In article <1992Dec23.185031.5218@murdoch.acc.Virginia.EDU> ccb8m@onyx.cs.Virginia.EDU (Charles C. Bundy) writes:
>In article <1992Dec22.153943.20019@sol.ctr.columbia.edu> jerry@msi.com (Jerry Shekhel) writes:
>>Andy Finkel (andy@cbmvax.commodore.com) wrote:
>>: >
>>: >Right, but there's nothing preventing a nasty application from bypassing
>>: >your ROM routines and talking directly to the disk hardware, screwing things
>>: >up.  On a system with properly-implemented memory protection, however, it's
>>: >much more difficult (if at all possible) to write such an application.
>>:
>>: If you are interested in the subject, you might want to do some research
>>: sometime.  The Internet Worm is fairly interesting, since it ran
>>: on Unix boxes.  (remember, Unix has protected memory).
>>:
>>
>>Yes, Unix has protected memory; that doesn't mean that it's bug free.  The
>>Worm took advantage of bugs in Unix, and took immense knowledge and ingenuity
>>to create.  On the other hand, a second-week computer science student would
>>have no problem intentionally screwing up a system without memory protection.

Jerry, you seem to have confused the file and memory protections available
in a multiuser multitasking OS (like Unix) with those of a single
user multitasking Os (like OS/2 or the AmigaOS).  In a single user OS,
the user is expected to assume responsibility for the programs they install
on their system.  OS/2 applications can do a lot of things that
a similar application on Unix would not be allowed, except from
the kernel.   For instance, applications can generate code dynamically
in any data segment, and execute it.  (with DOSCreateCSAlias), they
can intercept the mouse and keyboard data streams, they can read and
write I/O ports directly (without going through a device driver),
they can bypass the file system to read and write block devices at
the sector level, they can modify the system wide ram copy of
command.com, if they want to get tricky they can use the real mode
aspect of the DOS 3.x compatibility box or they can be a loadable device driver,
or replace a not-currently-in-use dynamic link library.  An application can 
even monitor (and read and write) the memory of another protected process
by using the PTrace call.   Now the OS/2 system can be configured to
not allow some of these functions, but you're giving up functionalify
if you, for instance, disable MSDOS compatibility, or the filesystem
direct (used for file system check and repair utilities).

Basically, BY DESIGN, the OS/2 system is an open one.  The memory protection
and file system protection is not designed to be a defense against
virus and virus like programs.  Nor does it act like one.  The OS/2
protections are instead entirely appropriate for a single user system;
they protect against errant programs accidently overwriting the data
space of another process.

You've got me curious now;  have you had much OS/2 programming experience ?
What sort of programming do you do (application or system level) and with
what OS ?   This isn't meant to be rude (and I apologize in advance if
it comes off that way) but I'd kind of like to know what basis you use for
the positions you forcefully advance.

			andy
-- 
andy finkel		andy@cbmvax.commodore.com

"Unix is the Operating System of the future, and always will be."

Any expressed opinions are mine; but feel free to share.
I disclaim all responsibilities, all shapes, all sizes, all colors.
Newsgroups: comp.sys.amiga.advocacy