ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (11/28/90)
I know I'm on record as saying that memory protection isn't a very important thing to add to the Macintosh system. But, thinking about it, I've come across an exception I'd like to make to this statement: MacsBug. It would be very useful if a resident debugger could protect itself against other software running amuck (whether this be rogue applications, or the system itself). It would also greatly improve the debugger's ability to diagnose problems. And I think it can be done with minimal impact on the rest of the system. It could very well be the single biggest contribution Apple could make to the reliability of Macintosh software generally. How about it, Apple? Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00 To someone with a hammer and a screwdriver, every problem looks like a nail with threads.
anders@verity.com (Anders Wallgren) (11/28/90)
In article <2371.27539d74@waikato.ac.nz>, ldo@waikato (Lawrence D'Oliveiro, Waikato University) writes: >I know I'm on record as saying that memory protection isn't a very important >thing to add to the Macintosh system. But, thinking about it, I've come >across an exception I'd like to make to this statement: MacsBug. > >It would be very useful if a resident debugger could protect itself >against other software running amuck (whether this be rogue applications, >or the system itself). It would also greatly improve the debugger's >ability to diagnose problems. And I think it can be done with minimal >impact on the rest of the system. > I fail to see how this is different from protecting all applications from each other, both in scope and effect. anders
jxf@castor.cis.ksu.edu (Jerry Frain) (11/28/90)
anders@verity.com (Anders Wallgren) writes: >In article <2371.27539d74@waikato.ac.nz>, ldo@waikato (Lawrence D'Oliveiro, Waikato University) writes: >>I know I'm on record as saying that memory protection isn't a very important >>thing to add to the Macintosh system. But, thinking about it, I've come >>across an exception I'd like to make to this statement: MacsBug. >> >>It would be very useful if a resident debugger could protect itself >>against other software running amuck (whether this be rogue applications, >>or the system itself). It would also greatly improve the debugger's >>ability to diagnose problems. And I think it can be done with minimal >>impact on the rest of the system. >I fail to see how this is different from protecting all applications >from each other, both in scope and effect. Agreed. A debugger is just an application, after all, whose data space is no more important (even less important, in most cases) than the space claimed by other applications. It seems rather hypocritical to claim that applications, and more importantly, the operating system, do not require protection from other applications, but the debugger does. --Jerry Frain, jxf@cis.ksu.edu
peirce@outpost.UUCP (Michael Peirce) (11/28/90)
In article <2371.27539d74@waikato.ac.nz>, ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > > I know I'm on record as saying that memory protection isn't a very important > thing to add to the Macintosh system. But, thinking about it, I've come > across an exception I'd like to make to this statement: MacsBug. > > It would be very useful if a resident debugger could protect itself > against other software running amuck (whether this be rogue applications, > or the system itself). It would also greatly improve the debugger's > ability to diagnose problems. And I think it can be done with minimal > impact on the rest of the system. > > It could very well be the single biggest contribution Apple could make > to the reliability of Macintosh software generally. > > How about it, Apple? I don't know about Apple, but Jasik's debugger has just added this sort of feature. In fact, it will detect when your program tries to write into another programs space! Really handy when you've got code running amuck. Of course you do need an MMU equiped Mac for this to work... -- michael -- Michael Peirce -- {apple,decwrl}!claris!outpost!peirce -- Peirce Software -- Suite 301, 719 Hibiscus Place -- Macintosh Programming -- San Jose, California 95117 -- and Consulting -- (408) 244-6554
kaufman@Neon.Stanford.EDU (Marc T. Kaufman) (11/28/90)
In article <2371.27539d74@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes:
.It would be very useful if a resident debugger could protect itself
.against other software running amuck (whether this be rogue applications,
.or the system itself). It would also greatly improve the debugger's
.ability to diagnose problems. And I think it can be done with minimal
.impact on the rest of the system.
This feature is now available with Jasik's Debugger. It even helps catch
simple bugs, like trying to use the contents of location 0.
Marc Kaufman (kaufman@Neon.stanford.edu)ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (11/28/90)
In <1990Nov28.031713.14035@maverick.ksu.ksu.edu>, jxf@castor.cis.ksu.edu (Jerry Frain) says, "A debugger is just an application, after all, whose data space is no more important (even less important, in most cases) than the space claimed by other applications." Surely that goes for the OS as well...? Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00 To someone with a hammer and a screwdriver, every problem looks like a nail with threads.
jtt@cunixd.cc.columbia.edu (James T. Tanis) (11/29/90)
Protection _should_ be a standard part of every modern OS. It's a crime that it is not implemented more often on micros. What exactly does jasik's program do? does it only trap writes of programs one is tracing through? I think TMON gives you the ability to trap writes in specified areas. It should not be too hard to make it sense out of bounds writes (it _is_ extensible, after all) -JT
ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (11/29/90)
Excuse my previous cryptic comment, let's try again. In <1990Nov28.031713.14035@maverick.ksu.ksu.edu>, jxf@castor.cis.ksu.edu (Jerry Frain) says, "A debugger is just an application, after all, whose data space is no more important (even less important, in most cases) than the space claimed by other applications." What do you mean by "just an application"? Are you perhaps implying that the OS (and other applications) may need protection from the debugger? Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
russotto@eng.umd.edu (Matthew T. Russotto) (11/29/90)
In article <1990Nov28.051104.21946@Neon.Stanford.EDU> kaufman@Neon.Stanford.EDU (Marc T. Kaufman) writes: >This feature is now available with Jasik's Debugger. It even helps catch >simple bugs, like trying to use the contents of location 0. Ever tried to run ShufflePuck Cafe with this mode on? (it makes some really strange references-- it does an LEA $1FC, A1 .... MOVE.W D2, -$1FC(A1) --- your register numbers may vary :-) ) -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.
kaufman@Neon.Stanford.EDU (Marc T. Kaufman) (11/29/90)
In article <1990Nov28.192647.8332@cunixf.cc.columbia.edu> jtt@cunixd.cc.columbia.edu (James T. Tanis) writes: >What exactly does jasik's program do? does it only trap writes of programs >one is tracing through? It sets the MMU so that the program can't reference (read or write) out of it's own space (and maybe the System heap) without trapping. Marc Kaufman (kaufman@Neon.stanford.edu)
jxf@castor.cis.ksu.edu (Jerry Frain) (11/29/90)
ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >Excuse my previous cryptic comment, let's try again. >In <1990Nov28.031713.14035@maverick.ksu.ksu.edu>, jxf@castor.cis.ksu.edu >(Jerry Frain) says, >"A debugger is just an application, after all, whose data >space is no more important (even less important, in most cases) >than the space claimed by other applications." >What do you mean by "just an application"? I am not sure what you are asking here. The debugger is an application like any other, I hope you agree. Quite often, ensuring the integrity of the debugger is not as important as protecting the data of other programs running on the system (e.g. - the OS). > Are you perhaps implying >that the OS (and other applications) may need protection from the debugger? Yes! All applications, your precious debugger included, should not be able modify the memory space of *other* programs. You will note that this should not encompass the development-time debugging involved in creating programs (but, I am unfamiliar with the way that Mac debuggers are implemented). Further, and more importantly, applications should not be able to write in OS memory space. In a generic sense, there exist circumstances where it is necessary to use a debugger to read/write to kernel memory (take it from someone who is not a stranger to using adb on a running Unix kernel), however I am not sure that this is ever necessary in the case of MacOS. There is no excuse for not utilizing modern (and abundant!) memory protection hardware. Simple, basic, controls for protecting system integrity. That's not too much to ask now, is it? IBM will soon make OS/2 their standard. Preemptive multitasking, memory protection, etc. With the advent of window systems that rival the Finder, coupled with the power of a command shell, Apple will be left out in the cold if it does not pick up on these very important concepts, soon. But I digress... -- Jerry Frain -- Systems Programmer Kansas State University Department of Computing & Info Sciences Internet : jxf@cis.ksu.edu Manhattan, Kansas UUCP : ...!rutgers!ksuvax1!jxf
francis@magrathea.uchicago.edu (Francis Stracke) (11/30/90)
In article <1990Nov29.025924.7662@maverick.ksu.ksu.edu> jxf@castor.cis.ksu.edu (Jerry Frain) writes: >Yes! All applications, your precious debugger included, should not be >able modify the memory space of *other* programs. You will note that >this should not encompass the development-time debugging involved in >creating programs (but, I am unfamiliar with the way that Mac debuggers >are implemented). How are you going to get around it? Either the debugger is locked out or it isn't. >Further, and more importantly, applications should not be able to write >in OS memory space. The fact is, though, that there are Mac apps that *do*. Worse, there are gazillions that depend on being able to *read* low RAM, given that Apple describes low-memory globals in Inside Mac. The effort involved in converting them all would be enormous. (And I'm not sure I understand what's so terrible about it. In a multiuser environment, there are security questions; but, on a Mac, you can't run into that. Responsible access shouldn't break things too badly.) >There is no excuse for not utilizing modern (and abundant!) memory >protection hardware. How about "most Macs don't have it"? Pluses, SEs, Classics, LCs, most IIs. >Simple, basic, controls for protecting system integrity. That's not too >much to ask now, is it? IBM will soon make OS/2 their standard. >Preemptive multitasking, memory protection, etc. With the advent of >window systems that rival the Finder, coupled with the power of a >command shell, Apple will be left out in the cold if it does not pick >up on these very important concepts, soon. Don't be so sure. Most people aren't going to be affected by (let alone understand) preemptive multitasking & memory protection. Well- written programs don't need such things; and most consumers just use commerical software (am I wrong here? It is my impression, based on what I see.), which (hopefully) is done right--at least right enough not to break. And all the window systems & command shells in the world can't beat the fact that the IBM world is full of non-windowing programs that don't even have a common Clipboard. | Francis Stracke | My opinions are my own. I don't steal them.| | Department of Mathematics |=============================================| | University of Chicago | Until you stalk and overrun, | | francis@zaphod.uchicago.edu | you can't devour anyone. -- Hobbes |
ewright@convex.com (Edward V. Wright) (11/30/90)
In article <1990Nov29.025924.7662@maverick.ksu.ksu.edu> jxf@castor.cis.ksu.edu (Jerry Frain) writes: >Yes! All applications, your precious debugger included, should not be >able modify the memory space of *other* programs. You will note that >this should not encompass the development-time debugging involved in >creating programs (but, I am unfamiliar with the way that Mac debuggers >are implemented). ?? I am not sure what you mean by this. One of the common functions of a debugger is to modify the value of variables in a program being debugged. And what is the difference between development-time debugging and ????-time debugging (whatever you are contrasting it to)? >Simple, basic, controls for protecting system integrity. That's not too >much to ask now, is it? IBM will soon make OS/2 their standard. I'm not sure what to make of this, either. Maybe IBM will make OS/2 (half an operating system :-) *its* standard, but OS/2 has been a complete disaster in terms of user acceptance. The only real enthusiasm in the PC World these days is for Microsoft Windows 3. >Preemptive multitasking, memory protection, etc. With the advent of >window systems that rival the Finder, coupled with the power of a >command shell, Apple will be left out in the cold if it does not pick >up on these very important concepts, soon. Huh? Since when is the Finder a "windowing system?" It's just an application that launches other applications.
siegel@endor.uucp (Rich Siegel) (11/30/90)
In article <1990Nov29.025924.7662@maverick.ksu.ksu.edu> jxf@castor.cis.ksu.edu (Jerry Frain) writes: >I am not sure what you are asking here. The debugger is an application >like any other, I hope you agree. Quite often, ensuring the integrity >of the debugger is not as important as protecting the data of other >programs running on the system (e.g. - the OS). I disagree. A debugger is definitely not "an application like any other". A machine-level debugger functions at a level where the state of the system is unknown - it may be suspended, crashed, or simply in some transitional state - and no system services (event and screen management, for example) may be accessible. Furthermore, a machine-level debugger has to be MUCH more aware of the system context (e.g. memory addressing spaces, virtual address mapping, register states) than any "normal" application. >Yes! All applications, your precious debugger included, should not be >able modify the memory space of *other* programs. You will note that >this should not encompass the development-time debugging involved in >creating programs (but, I am unfamiliar with the way that Mac debuggers >are implemented). If a debugger can't modify other memory spaces, then its usefulness as a tool is severely limited - a debugger will typically need to set break- points, and edit memory, as part of the development cycle. (The average computer user doesn't know a debugger from Shinola, and typically doesn't use one in his day-to-day use of the machine.) Memory protection on the Mac is a tricky problem, because the OS, Toolbox, and application code are so tightly coupled, and applications often have legitimate reasons to access OS space. That doesn't make it impossible, though. I agree in principle with the need, but for all practical purposes, I believe that software that doesn't crash in the first place is the best way to go - whether it stomps on other parts of the system or not, a crash interferes with the user's ability to get work done, and therefore it is a good thing to avoid. R. Rich Siegel Symantec Languages Group Internet: siegel@endor.harvard.edu "...she's dressed in yellow, she says 'Hello, come sit next to me, you fine fellow..."
jxf@castor.cis.ksu.edu (Jerry Frain) (11/30/90)
In article <4857@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: >In article <1990Nov29.025924.7662@maverick.ksu.ksu.edu> jxf@castor.cis.ksu.edu (Jerry Frain) writes: > >>I am not sure what you are asking here. The debugger is an application >>like any other, I hope you agree. Quite often, ensuring the integrity >>of the debugger is not as important as protecting the data of other >>programs running on the system (e.g. - the OS). > > I disagree. A debugger is definitely not "an application like >any other". My original point was that protecting the integrity of the debugger's memory space is no more important than protecting the memory space of other programs, in particular, the OS. IN THIS RESPECT, the debugger is no different from any other program. To argue against this point is absurd. > If a debugger can't modify other memory spaces, then its usefulness >as a tool is severely limited - a debugger will typically need to set break- >points, and edit memory, as part of the development cycle. Truly this is the primary objective of the debugger. This can also be accomplished without giving the debugger free reign over the machine; most modern multitasking OSs support debugging activity while simultaneously providing memory protection for other processes quite well. Supporting the principle that all programs may run rampant throughout the entire range of memory offered by the machine, while other programs are attempting to use this memory, is ludicrous. The debugger should operate under the grace of the OS, not on the same level of the OS. >I believe that software that doesn't crash in the first place is the best >way to go - whether it stomps on other parts of the system or not, a >crash interferes with the user's ability to get work done, and therefore >it is a good thing to avoid. Personally, I'd rather have a crash than have a program "stomp on other parts of the system." Encountering a dangling pointer which misbehaves only enough to go out and twiddle with a couple of bits in, say, my hard disk driver, _can_ be worse than an outright crash *or* writing in the memory space of my favorite debugger. --Jerry -- Jerry Frain -- Systems Programmer Kansas State University Department of Computing & Info Sciences Internet : jxf@cis.ksu.edu Manhattan, Kansas UUCP : ...!rutgers!ksuvax1!jxf
oster@well.sf.ca.us (David Phillip Oster) (12/03/90)
In article <4857@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: >I believe that software that doesn't crash in the first place is the best >way to go Here! Here! and that is why the debugger should grab the MMU and protect itself: it is precisely while you are debugging software that you are working with buggy software. Once software is debugged it isn't buggy. Rich is right, it is much easier job for a debugger to protect itself than it is for the Mac O.S. to protect every program from every other, and itself, and still allow legitimate access, since legitimate access is so unstructured. It would be nice, but I'd rather have the easy part early than the nice one, when it happens to get finished. -- -- David Phillip Oster - At least the government doesn't make death worse. -- oster@well.sf.ca.us = {backbone}!well!oster
rang@cs.wisc.edu (Anton Rang) (12/04/90)
In article <1990Nov29.201754.10384@midway.uchicago.edu> francis@magrathea.uchicago.edu (Francis Stracke) writes: >How are you going to get around it? Either the debugger is locked out >or it isn't. If the debugger's running as a separate application, it shouldn't be able to get at another application's address space, by default. There should be a trap which attaches the debugger to another application, or some mechanism like that. Low-level debuggers are special, of course. Since, as Rich pointed out, the machine state is unknown, they basically need to be able to get at everything and can't rely on using OS calls for much. >>Further, and more importantly, applications should not be able to write >>in OS memory space. > >The fact is, though, that there are Mac apps that *do*. Worse, >there are gazillions that depend on being able to *read* low RAM, >given that Apple describes low-memory globals in Inside Mac. There's an easy way to fix this for the most common cases. Trap all attempts to read and write to low memory, and emulate them. For the cases where the application is only affecting itself, this will work fine, and the performance hit is unlikely to be too bad if the most common cases are optimized. It's tougher for INITs, CDEVs, DRVRs, etc. which want to live in the operating system. I haven't had enough experience writing these or playing with the very low-level OS routines to know how hard it would be to let some of these live happily in the system. Most likely, the best solution would be to provide a supported interface for dumping code in (e.g. a way to do a SetTrapAddress that will function globally and a way to install a chunk of memory as shared). >>There is no excuse for not utilizing modern (and abundant!) memory >>protection hardware. >How about "most Macs don't have it"? Pluses, SEs, Classics, LCs, most IIs. Yup, real problem. Hopefully, though, this can be integrated into the VM stuff, which won't be around on the low-end machines anyway. I only have an SE, but I'd really like to see memory protection on a Mac II-series machine if I buy one, anyway. >Don't be so sure. Most people aren't going to be affected by (let >alone understand) preemptive multitasking & memory protection. Well...not affected much, maybe. There are some problems, though, that I run into, even when I'm not programming. * It's difficult to write file transfer programs so that they'll keep going while something else has control of the computer. I've had "Mirror" abort a file transfer because the remote end is unhappy with the computer stopping for 60 seconds. * If one of my applications has a bug (and there's plenty, even in "well-written" software), I'd like to be able to abort it without needing to reboot. I really hope that Apple gets this right. :-) Anton +---------------------------+------------------+-------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison | +---------------------------+------------------+-------------+
ingemar@isy.liu.se (Ingemar Ragnemalm) (12/05/90)
siegel@endor.uucp (Rich Siegel) writes: >Memory protection on the Mac is a tricky problem, because the OS, Toolbox, >and application code are so tightly coupled, and applications often have >legitimate reasons to access OS space. That doesn't make it impossible, >though. I agree in principle with the need, but for all practical purposes, >I believe that software that doesn't crash in the first place is the best >way to go - whether it stomps on other parts of the system or not, a >crash interferes with the user's ability to get work done, and therefore >it is a good thing to avoid. Software that doesn't crash? Ever seen a totally bug-free program? I havn't. Ever seen MS Word bomb? I don't need protected mode that much when running unifinder, but under Multifinder, it is very much needed. Is it that hard to do? I really don't know much of this, but I'd imagine a flag on applications that tells if they allow protected mode. Is it possible to protect only against writing and not against reading? PS: Is there a "crashsaver" anywhere that works on Mac II's? Mine works like a dream on Plus and SE, but when I try to jump out of a bomb on a II, it hangs. -- Ingemar Ragnemalm Dept. of Electrical Engineering ...!uunet!mcvax!enea!rainier!ingemar .. University of Linkoping, Sweden ingemar@isy.liu.se