Text File

Subject: RISKS DIGEST 13.26 [sic] REPLY-TO: risks@csl.sri.com

RISKS-LIST: RISKS-FORUM Digest Friday 6 March 1992 Volume 13 : Issue 26

*** THIS IS THE REAL RISKS-13.26. THE PREVIOUS ISSUE BORE THAT MARK IN *** ***TWO PLACES AND RISKS-13.25 IN THE MAIN LINE. IT WAS REALLY RISKS-13.25***

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents: [Happy Birthday to Michelangelo.] Name this risk... [Primative logic] (Michael Travers via Rex Black) Mouse restrictions on American Airlines (Bob Frankston) Exporting Apples (Burt Kaliski, RSA Laboratories) Bargain Harold finds computers no bargain (Dave Wortman) Re: Sizewell (and RISKS) on UK TV (Pat Place) Risks of Automated Phone Operators (Charles Olson) Speed-droid tickets junked car (Jane Beckman) Risks of Barcoded money (Mark Gonzales) Safeway "Frequent Shoppers Club" (Jeremy Epstein) Re: Musical Risks (Katz, rwk) Re: Bureau of Centralization -- Phone Taps (Peter Wayner, Steve Dever) New Legislation on Computer Security (Lance J. Hoffman) Re: Michelangelo (anonymous, Graham Mainwaring) Technical terminology -- and viruses (Brian Rice) Re: A RISK architecture? (DEC's Alpha) (Steve Bellovin, Tom Blinn) Imprecision not considered harmful (Eric Sosman)

The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others may be ignored! Contributions will not be ACKed. The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP folks. REQUESTS please to RISKS-Request@CSL.SRI.COM. Vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR> CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 13, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". <CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.

----------------------------------------------------------------------

Date: Thu, 5 Mar 92 10:37:55 -0800 From: Rex Black <rex@devnet.la.locus.com> Subject: Name this risk... [Primative logic]

>From: Michael Travers <mt@media.mit.edu>

Toronto, Canada:

Archbisop George Cram enjoys a banana once in a while, but he's not the kind of primate that ape researchers had in mind. The University of Wisconsin's Regional Primate Research Center sent Cram, primate (senior archbishop) of the Anglican Church of Canada, a questionnaire while preparing an international directory of primatology. The envelope was addressed to "George Cram, Primates World Relief and Development Fund."

The Reverend Michael Ingham, secretary for the senior archbishop, suggested in a letter of reply that "primates in your study are perhaps of a different species. While it is true that our primate occasionally enjoys bananas, I have never seen him walk with his knuckles on the ground or scratch himself publicly under the armpits," Ingham said. "There are a mere 28 Anglican primates in the whole world," he said. "They are all males, of course, but so far we have had no problems of reproduction."

The research center's director, John Hearn, promised to strike the church from a computer database and added in a letter to Ingham; "In our zeal to develop a comprehensive directory, we have strayed on this occasion from the arboreal to the spiritual."

------------------------------

Date: Fri 6 Mar 1992 12:52 -0500 From: <Bob_Frankston@frankston.std.com> Subject: Mouse restrictions on American Airlines

Date: 03-03-92 07:59:18 PM MEMO From: John Bartlett [WITH PERMISSION TO RISKS]

I'm sitting on an American flight to Dallas working on a presentation for tomorrow and I can't believe what I've just been told. A flight attendant came over and politely said that it was ok to use my portable (Compaq LTE) on the plane but that according to a new regulation, I would not be able to use my mouse (Microsoft ballpoint)! I of course thought she was joking but apparently according to a new regulation only portables with a built-in mouse are allowed. She actually showed me the regulation which specifically states that mice with umbilical cords can't be used because of interference with flight navigation systems.. This basically limits the use of mice to Mac Powerbooks and a few obscure portables. Using Freelance without a mouse is just about impossible. I tried to argue that there wasn't any difference between a mouse connected with a cord and one that is internal. The flight attendant spoke to the captain in this instance let it go but all should be aware of this new American policy when flying.

------------------------------

Date: Fri, 6 Mar 92 15:33:22 PST From: burt@RSA.COM (Burt Kaliski, RSA Laboratories) Subject: Exporting Apples

The Wall Street Journal, "Apple Computer Backs Technology of Two Companies," by G. Pascal Zachary, March 4, 1992, states:

In connection with its support for data encryption, Apple said it had applied to the U.S. Commerce Department for the right to export software containing the technology, which is generally restricted as a sensitive technology. Apple said it expects to receive export approval because the National Security Agency, a leading agency on cryptographic policy, has reviewed the design and raised no objections to it. [The two companies are Adobe and RSA. The Tail of Two Companies may wag the dog. Apple's InCider? PGN]

------------------------------

Date: Fri, 6 Mar 92 13:08:35 EST From: Dave Wortman <dw@swatter.fly.toronto.edu> Subject: Bargain Harold finds computers no bargain

Bargain Harold's, a local discount retail chain has just been petitioned into receivership by its creditors. 160 stores across Canada will likely be closed. There are several RISKS related reasons for this situation:

- new management spent $15M on store refurbishment and on a computerized point-of-sale system with centralized inventory management. This was $7M more than was authorized by the companies creditors.

- the companies immediate financial difficulties are being blamed on several factors including undetected errors in the new management information system. Apparently this system was incorrectly predicting gross margin on sales and profits. Based on this incorrect information management built up excessive inventories and were unable to reliablely predict the company's annual profit. A profit estimate of $500K on Oct 2 was changed the next day to a estimated loss of $3-4M. The projected loss grew rapidly over the next few months (currently $20M).

Details on the reasons for the MIS system failure are not yet available.

------------------------------

Date: Fri Mar 06 08:56:40 1992 From: Pat Place <prp@sei.cmu.edu> Subject: Re: Sizewell (and RISKS) on UK TV

I have not seen the Channel 4 TV program and cannot comment on the angle taken in that presentation. However, the impression I am getting from this forum is that the only protection mechanism for Sizewell B is the 100,000 lines of code software system, about which we could reasonably be concerned.

I would like to point out that I have been led to believe that a secondary protection system exists that also has the capability of shutting down the reactor and that this secondary system is a more traditional hardware based system. Further, I have been told that these two systems are independent. So, before we raise concerns over the safety of Sizewell B, can we have all the facts relating to the protection mechanism and not just the worry over the software?

Pat Place prp@sei.cmu.edu

------------------------------

Date: Thu, 5 Mar 92 23:16:04 -0500 From: olson@husc.harvard.edu Subject: Risks of Automated Phone Operators (RE: RISKS-13.24)

Our moderator's comments about the potential fraud problems with AT&T's operatorless collect-call system reminded me of my one experience with it. I had to call AAA, for the obvious reason that the car I was traveling in had decided to fry its clutch, and they tell you to call collect. The conversation ran as follows:

Me: [Dial 0 + number] Pleasant recorded voice: "...If you are making a collect call, please press `1-1' now." [or some such] Me: [Key 1-1] Voice: "Please say your name." Me: "Charles Olson" Voice: "Please wait while we determine if your call will be accepted..." [brrrring...brrrring.....] [click] AAA recording: "Thank you for calling | AT&T recording: "You have a collect AAA Emergency Road Service. We will | call from [my voice] Charles Olson. accept your collect call. If you... | If you accept this call, please...

Me: "AAARRRGGGHHHH!!!!!!!" [SLAM!]

------------------------------

Date: Thu, 5 Mar 92 18:59:58 PST From: jane@stratus.swdc.stratus.com (Jane Beckman) Subject: Speed-droid tickets junked car

I snagged this one from the alt.folklore.urban group, but it doesn't seem to be a legend, but rather a risks illustration. There are already lots of cars out on the road, where the new owner has never bothered to file the change of ownership (why you should always go with a buyer to re-register the car). But a junkyard? How many states don't have any provision for the owner declaring the car dead, but rely on a possibly unscrupulous junkyard to send in paperwork (and/or plates)? Having sold a junked car myself, once, I wondered about whether the change of title would actually be sent in, or if there was a black market for plates. (My understanding of California law is that sending in the "I've sold it" slip to the DMV does not actually modify the computer records on the car. That must be done by title change. I have no idea what the procedure may be in other states.)

Also, it brings up the issue of identity, when a car is "salvaged," and the only witness who can establish an identity for the driver is a camera. In a manned pullover, the cop asks for a driver's license and checks it against the registration, and if the owner isn't in the car, that person had better have a good story. There is no hope of catching a person who is operating a vehicle illegally if the only enforcement is robotic. Jane Beckman [jane@swdc.stratus.com]

Ghost Car Speeding? Photocop Snaps Auto `Retired' 8 Months Ago By Stephen Hunt, The Salt Lake Tribune [last month sometime]

Susan Johnson laid to rest her 1984 Toyota Tercel eight months ago. The car had 200,000 miles on it. When it quit running in June, she sold it to a wrecking yard for $50. She was sure she'd seen the last of it.

But according to a traffic ticket Ms. Johnson received in the mail last week, the car has been resurrected and is speeding about the streets of West Valley City. The ticket says Photcopy -- a computerized ticketing system that snaps pictures of speeding carss -- caught the car traveling 47 miles per hour in a 35 mph zone on Jan. 10.

Since the car was not even running last time she saw it, Ms. Johnson is wondering how it could be breaking speed laws. "I was so surprised," she said. She believes someone must be using her old license plates, which were left on the car when she sold it.

According to Utah law, license plates are to be returned to the state Motor Vehicle Division when a car is sold. However, once the title has been signed and delivered to the new owner, the previous owner is no longer liable, according to the DMV.

Ms. Johnson was to appear today in West Valley City 5th Circuit Court to deal with the ticket. There, she will be allowed to see the photo and, she hopes, prove her innocence.

Photocop uses radar, a computer and a camera to snap pictures of speeders that show both the car's license plate and the driver. "I hope it's not someone who looks like me," Ms. Johnson said.

Photo radar has become a controversy at the Legislature. Two bills regarding the device are before lawmakers. One would limit the use of photo-radar to school zones only; another would ban it altogether.

Opponents say Photocop smacks of Big Brother.

Imagine That!

Bert Nelson, Weber State University, bnelson@csulx.weber.edu

------------------------------

Date: Wed, 4 Mar 92 12:06:52 PST From: markg@ichips.intel.com Subject: Risks of Barcoded money

The Nova show on PBS last night (3 Mar 1992) was about banknote printing technology, covering the endless battle between the banknote printers and the forgers.

One interesting item they mentioned in passing was that some new Dutch banknotes have a barcoded serial number, supposedly as a means of detecting forged notes, which would have a duplicated, or unused serial number. Whenever a batch of notes gets back to the central bank all their serial numbers are checked by computer.

The RISKS of this are pretty obvious. Cash will no longer allow anonymous transactions. It would be a simple step for ATMs to make a record of the serial numbers of all notes they issue to each customer. It would also be simple and 'logical' for stores and supermarkets to use their bar code scanners to check the serial numbers of notes they receive (in case of forgery).

The Police could also check the numbers of notes they confiscate in connection with crimes. Then citizens would have to explain why a bank note they were issued by an ATM at 08:31 on 1/2/99 was found on the person of a drug dealer at 11:20 on 1/2/99, while no stores have records of that note being spent in the intervening hours: "If you did not spend the money at an authorized retail outlet, what did you do with it, sir?"

Barcoded bank notes was a pretty obvious step, but it seems to me that the unpleasant civil liberties consequences to us all far outweigh the benefits of catching a few forgers.

Mark Gonzales

------------------------------

Date: Thu, 5 Mar 92 10:41:23 EST From: epstein%trwacs@uunet.UU.NET (Jeremy Epstein) Subject: Safeway "Frequent Shoppers Club"

Safeway stores in the Washington area (and perhaps other areas) recently introduced a "Frequent Shoppers Club". By filling out a form which includes various demographic and financial information, you get discounts (typically 10%) on a few sale items each week (i.e., 10% below the price offered non-members). There's no cost to join the club.

Safeway is obviously trying to build a database of buying habits which can then be resold to advertisers for targeted advertising. Many people are up in arms about "invasion of privacy". Safeway has a program now where every time you use your frequent shoppers card, you're automatically entered in a mini-lottery (to encourage use of the card).

What strikes me as curious is that people don't seem to realize that the RISK is already there. With UPC scanners coupled with check cashing cards, there's already the opportunity to gather and correlate the information for a large fraction of the population. Are there any laws which prevent the grocery store from selling that information? The check cashing application forms don't preclude the store from doing whatever it wants with the non-financial information. Are there any instances of stores which actually do the correlation and resell the information?

I'm also curious what reactions have been to these sorts of programs in other parts of the country/world.

Jeremy Epstein, Trusted X Research Group, TRW Systems Division, Fairfax, Virginia +1 703/803-4974 UUCP: uunet!trwacs!epstein

------------------------------

Date: Thu, 5 Mar 92 18:52:26 EST From: katz@merit.edu Subject: Re: Musical Risks

The obvious solution to the DX-7 dilemma is to sample the patches used in the performance using a sampling synthesizer. Of course, something is lost in the process (especially if the timbre is modified dynamically). You could always sample the entire performance, of course, but then you may as well just roll a tape.

The band Pere Ubu seems to have left its old Moog synth (knobs and patch cords and all) behind on the last tour, but not before sampling it into a slightly more modern synth.

------------------------------

Date: Thu, 5 Mar 92 21:24:46 -0500 From: rwk@crl.dec.com Subject: Re: Musical Risks (RISKS-13.25 [so-called])

Geoff Kuenning discusses the risk of not having DX-7s available to classical music in 20 years time.

(Hmm, mine's about a third of the way there and still going strong).

Anyway, it's really not that hard to do a DX-7 in software if you have the processing power. In twenty years, I'll expect my wristwatch to have that much processing power, if not my athletic shoe!

------------------------------

Date: Fri, 6 Mar 1992 18:16:20 GMT From: wayner@cs.cornell.edu (Peter Wayner) Subject: Re: Bureau of Centralization -- Phone Taps

USA Today reports in Friday, March 6th paper that the Dept. of Justice is floating a proposal that would require phone companies to centralize phone tapping and make it easier for law enforcement agencies to listen in. They note that this would raise monthly phone bills for all consumers.

Peter Wayner Department of Computer Science Cornell Univ. Ithaca, NY 14850 EMail:wayner@cs.cornell.edu Office: 607-255-9202 or 255-1008

------------------------------

Date: Fri, 6 Mar 92 13:34:48 PST From: Steve.Dever@eng.sun.com (Steve Dever) Subject: Re: Bureau of Centralization -- phone taps

The 6-Mar-1992 San Jose Mercury News has an article about this on page 5A. The article is titled: "White House wants consumers to pay bill for better wiretaps." According to the article, the Justice Dept. is worried that "the widespread use of digital transmission, fiber optics and other technologies" make it difficult for government agencies to intercept transmissions. The Justice Dept. is proposing a bill which would direct the FCC to "devise rules to give law enforcement agencies access to conversations for court ordered wiretapping." Phone companies would then be required to follow the rules. The bill would also authorize the FCC to permit the phone companies to increase rates to cover the cost of implementing the rules.

The proposal has been discussed with Sen. Ernest Hollings, chair of the Senate Commerce Committee which oversees the FCC. Steve Dever

------------------------------

Date: Fri, 06 Mar 92 17:03:12 -0500 From: wayner@cs.cornell.edu (Peter Wayner) Subject: Re: Bureau of Centralization -- phone taps

I've had a few second-order thoughts about the matter.

0) The Justice department seems to want to ensure that there is some place in the system where the signal can be easily turned into sound. It does not seem to prohibit individual people from encrypting their messages. It just means that the phone company needs to provide a tap.

1) Centralized phone tapping doesn't necessarily mean less privacy. I can imagine a huge bureaucracy at the local phone companies' tap center filled with mean clerks who would demand to see the proper forms authorizing the taps. "No, I'm sorry Officer. You didn't submit 44/22-G that authorizes the recording of conversations from another state that are forwarded to a third state by a central routing office without being delivered to the phone in your juristiction. A 44/22-F authorizes only cross-county juristiction expansion."

Now each police department probably has its own set of mikes and tape recorders and can place them as it wishes.

2) I don't necessarily believe that the above will happen.

------------------------------

Date: Fri, 6 Mar 92 12:16:38 EST From: Lance J. Hoffman <hoffman@seas.gwu.edu> Subject: New Legislation on Computer Security

Recently introduced legislation may be of interest to RISKS readers. S. 2198, the Intelligence Reorganization Act of 1992 and HR 4165, the National Security Act of 1992, essentially give responsibility for all comsec to the National Security Agency and for all information security to them also. This, of course, would completely reverse, existing structure which has just been in place for a couple of years, and apparently take much responsibility away from the National Institute of Standards and Technology (NIST) in the Dept. of Commerce and put it (back) at NSA in the Defense Dept.

If enacted, this would have important implications for export control and crypto policy, which are of interest to many RISKS readers. Lance Hoffman

Department of Electrical Engineering and Computer Science, The George Washington University, Washington, D. C. 20052 (202) 994-4955

------------------------------

Date: Thu 5 Mar 1992 19:34 -0500 From: [anonymous] Subject: Re: Michelangelo

I spent the day today clearing many viruses. In the last week xxxx and I have cleared over 80 Michelangelos from .... Also, we have cleared many Cascades, New Zealands, Joshis, and others. Easily over 120 infections in the last week.

You may have heard that just changing the date is an adequate defense; it is not. You may have heard that not using the computer that day is a defense; it is not. You may have learned many things; almost all of them untrue. All anyone needs to know is that Michelangelo is a very widespread virus. It is destructive. It can be removed only by using proper procedures. It is completely manageable and removable.

Procedures:

Detect the virus (Use any commercial or other package that is up to date) Cold Clean Boot (Turn off PC, insert DOS Startup notchless diskette, turn on PC) Copy first track into memory Copy partition table from virus (sector 1) into partition table of original (sector 7) in memory Copy original over virus in memory Zero the copy of the original in memory Write the result back to the first track.

As you can see, nothing magic, just plain old careful procedure.

Anyone who leaves a diskette in their boot drive by accident when they boot should have their wrist slapped.

------------------------------

Date: Thu, 05 Mar 92 22:10:45 EST From: octogard!graham@duke.cs.duke.edu (Graham Mainwaring) Subject: Re: Michelangelo (RISKS-13.21)

In RISKS-13.21, jcav@midway.uchicago.edu writes about his local news station omitting to mention that the Michelangelo virus only affects MS-DOS machines. I submit that this really isn't much of a problem, for the following reasons:

1. MS-DOS users are actually affected by the virus, so in their case, the report was correct and useful.

2. Macintosh users have such a frightening virus problem already that there are very few left who don't routinely disinfect their machines.

3. Everyone else is either sophisticated enough to understand the situation, or has a MIS department to call and get straightened out by.

A more serious problem is the entire area of media handling of Michelangelo. Why is this particular virus getting almost saturation-level coverage in the media? Is Michelangelo really any worse than Stoned, 1701, Jerusalem-B, or any of the other MS-DOS viruses that have been circulating lately?

Even worse, will people assume that once they have scanned their disks for Michelangelo, that the threat is over? After all, the fuss has quieted down. Why should it be necessary to do it again?

Internet: octogard!graham@deepthot.cary.nc.us BBS: +1 919 876 7213 UUCP: ...!duke!wolves!deepthot!octogard!graham WWIVnet: 1@9970

------------------------------

Date: Fri, 6 Mar 1992 14:16:41 -0500 From: rice@dg-rtp.dg.com (Brian Rice) Subject: Technical terminology -- and viruses

Here's another one for the "risks of posting to RISKS" file.

In RISKS-12.30, 11 Sep 1991, I wrote, concerning so-called beneficial viruses:

"...the idea of code roaming around in a network looking for opportunities to do good is what we technical types call `way cool.'"

In _Newsweek_, 20 Jan 1992, John Schwartz writes, concerning virtual- reality video games:

"When you shoot, your nemesis is blown to colorful smithereens-- a sight that is, to use a technical term, way cool."

It's just like William S. Burroughs said: "Language is a virus."

Brian Rice, DG/UX Software Quality Assurance, Data General Corp., Research Triangle Park, N.C. rice@dg-rtp.dg.com +1 919 248-6328

------------------------------

Date: Thu, 05 Mar 92 19:30:01 EST From: Steve Bellovin <smb@ulysses.att.com> Subject: Re: A RISK architecture? (DEC's Alpha)

Brian Randell describes how the Alpha uses imprecise arithmetic traps, and speculates that it's a risk to program correctness. With all due respect, I disagree. Based on my experience with imprecise interrupts on the 360/91, lo these many years ago, I would classify imprecise interrupts as more of a hassle when localizing faults, rather than any risk to the program's correct behavior. That is, the interrupts -- which typically signified erroneous program behavior -- still happened, and still caused the program to abort. But it took rather more debugging effort to figure out which instruction caused the trap. Unless one is relying the interrupt handler to perform the appropriate fix-up -- a technique that I regard as far more risky and non-portable than imprecise interrupts -- correct programs should not behave any differently.

He also describes the barrier instruction as a ``sop to DEC's technical conscience''. Not so. Its purpose is to help the programmer identify the offending instruction. And compilers can (and were able to) generate such instructions on appropriate boundaries. I recall vividly, 20+ years later, finding that a zero- divide fault took place 11 instructions after the offending divide, and after the divisor register had been overwritten with a non-zero value. But it had to be that instruction; there were only two divide instructions in the entire program, and the other referenced a still-intact constant.

If there is a danger here, it's from the hardware design itself. Pipelined architectures imply parallelism, of course, and that's harder to get right. But the hardware designers seem to do a better job which such things than do the software designers... --Steve Bellovin

------------------------------

Date: Thu, 5 Mar 92 15:46:23 PST From: "Dr. Tom @MKO, CMG S/W Mktg, DTN 264-4865 05-Mar-1992 1834" <blinn@dr.enet.dec.com> Subject: Alpha's "imprecise arithmetic traps" are nothing new..

In RISKS-13.25 (Thursday 5 March 1992) Brian Randell writes about the new Alpha RISC architecture and comments on its imprecise arithmetic traps.

Those of us who ever programmed the IBM System/360 Model 91 under OS/MVT (or, I'd imagine, other OSes) will recall that it, too, had imprecise interrupts, in large part because it provided (limited) pipelining and multiple issue of arithmetic instructions. I don't recall the details -- it has been a long time -- but as I recall it could overlap integer and floating point compute operations, and perhaps did multiple floating multiplies in parallel. In any case, the careless programmer could easily get the dreaded 0C5 ABEND, along with a generally useless dump, when one of the parallel operations failed.

IBM, in their infinite wisdom, did not provide a Trapb instruction to allow the programmer to force precise interrupts -- at least, I don't recall any such instruction. Instead, if you couldn't guess what was wrong by looking at the code, you could carry it to a different System/360 model (like the Model 75) that didn't provide the parallelism and get a precise interrupt.

What's neat about the Alpha design is, of course, that you can get precise traps when you need or want them, at some performance penalty, but you can go blazingly fast when you don't need that precision. Compared to other ways of addressing the problems implied by a pipelined multi-issue architecture, the Alpha approach seems rather clean and clever to me. But then, I may be biased, and I'm not an experienced computer architect.

Dr. Thomas P. Blinn, Digital Equipment Corporation, Digital Drive -- MKO2-2/F10 Merrimack, New Hampshire 03054 ...!decwrl!dr.enet.dec.com!blinn (603) 884-4865

------------------------------

Date: Fri, 6 Mar 92 09:49:45 EST From: eric@tardis.hq.ileaf.com (Eric Sosman x4425) Subject: Imprecision not considered harmful

In RISKS-13.25 (so-called), Brian.Randell@newcastle.ac.uk seems alarmed at the notion of imprecise delivery of instruction exceptions. I was similarly alarmed when I first heard of them ... twenty-plus years ago, with the IBM System/360 model 91. (I'm not claiming the 91 was the first such implementation, simply that is was the first in my personal experience.)

It is only sometimes useful to identify "the" instruction which blew up; usually a coarser localization will do. The imprecise-exception architectures I know of all provide an instruction which acts as a barrier, with the promise that no exception delivered after the barrier can be due to any instruction fetched before the barrier. The 360-91 used "BR 0,0": a "no-op" in the form of a pipeline-draining conditional branch. Compilers inserted this instruction at strategic locations like subroutine prologues and epilogues, or (if requested) between segments of code generated for different source statements.

Imprecise exceptions make it difficult to write trap handlers which fix up the results of failing instructions. I have written such handlers, but have never found them satisfactory -- the "correct" fix is too context-dependent to be dealt with by such a low-level approach. Error detection and correction work much better in the higher levels, and imprecise instructions don't make the superior approach impossible or even difficult.

Eric Sosman eric@hq.ileaf.com Interleaf, Inc. / Prospect Place, 9 Hillside Ave. / Waltham, MA 02154

------------------------------

End of RISKS-FORUM Digest 13.26 (the real one) ************************