NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/arch/9075

Internet Message Format | 1992-08-27 | 3.4 KB

Path: sparky!uunet!usc!cs.utexas.edu!sun-barr!news2me.ebay.sun.com!exodus.Eng.Sun.COM!rbbb.Eng.Sun.COM!chased
From: [e-mail] (David Chase)
Newsgroups: comp.arch
Subject: Re: Program behaviour (was Re: trapping speculative ops
Date: 27 Aug 1992 23:59:23 GMT
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 61
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
NNTP-Posting-Host: rbbb

In article <[e-mail]> [e-mail] (Stanley T.H. Chow) writes:
>Also, there are languages and systems that actually specify the
>behaviour for incorrect programs - typically, trap if dereferencing
>a wild pointer. Given that most MMUs do quite a good job, it is
>strange to force those compilers to generate slower code.

Note that the MMUs don't do a perfect job, else there'd be no market
for products like Purify.  People make performance tradeoffs.  I'd
like to stake out a little territory at the fast end of the curve.

Since all I proposed can be done in software (enabled or disabled with
a system call), you have no complaint -- the run-time systems for
those languages will request that traps be reported, and page zero
will be unmapped.

For C, this can be accommodated fairly easily by providing some way of
identifying loads that ought to fault.  Any "volatile" load or store
falls into this category.  You can use a bitmap of your text space, or
hash on the addresses, or precede the volatile loads with a tagged nop
instruction (on Sparc, "sethi #notzero,%g0").  Or, you can reserve one
destination register as the I-mean-it register, and generate code to
use that one when traps are required, and otherwise don't.  The trap
code can check whether or not a fault is required by the code.

>The question is whether
>the gain in performance justifies the lost in security. I expect
>different people will answer differently.

Since I propose a software solution, different people can get what
they want.

>I assume you mean no change to "Instruction Set Architecuture". You
>are certainly implying changes to "System Architecture".

Not necessary, but it helps.  A suitably motivated user can get this
for a Sparc box with an afternoon's hacking in non-OS code.  (I did
it.)  It works better if you get cooperation from the OS, but this
isn't required.  The penalty for actually taking the trap is pretty
stiff, but my hunch is that (once page zero is readable, and excluding
misaligned accesses) taken traps will be very rare.

>>Remember, we've got tools to help us debug our code.

>But only during the "debugging phase". What happens when the program
>is released into user hands?

That is up to the user and vendor.  Many people write code in C, which
means that (unless they use Centerline or Purify or some similar tool)
most of their array accesses are never, ever checked, let alone after
release.  Their pointer casts aren't checked, either.  You've got no
guarantee that the vendor did coverage testing of the code, unless
this is specified in the contract or advertised.  People seem happy
with the status quo.  Failing to trap some wild pointer accesses is a
small departure from the current state of the world, especially given
how easy it is to perform this check in debugging mode (let the MMU do
it, just as it does today).

Where this isn't appropriate, don't do it.  It's a software solution.

David Chase
Sun