[33549] in bugtraq
Re: http://www.smashguard.org
daemon@ATHENA.MIT.EDU (Nicholas Weaver)
Mon Feb 9 18:46:36 2004
Date: Sat, 7 Feb 2004 10:11:36 -0800
From: Nicholas Weaver <nweaver@CS.berkeley.edu>
To: Hilmi Ozdoganoglu <cyprian@purdue.edu>
Cc: Dave Paris <dparis@w3works.com>, bugtraq@securityfocus.com
Message-ID: <20040207101136.A21161@ring.CS.Berkeley.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.SOL.4.51.0402061528350.7316@herald.cc.purdue.edu>; from cyprian@purdue.edu on Fri, Feb 06, 2004 at 03:29:30PM -0500
On Fri, Feb 06, 2004 at 03:29:30PM -0500, Hilmi Ozdoganoglu composed:
>
> Agreed, the software based approach does not take a significant
> performance hit, but the hardware approach is transparent to the user
> and does not require recompilation of the source code. Therefore, all
> programs can run securely on a machine whether or not they are "compiled
> securely" (e.g. legacy software).
Not all control flow follows stack logic. So you can't claim
backwards compatibility on all programs.
What happens if you are compiling continuations, such as a
high-performance ML or scheme environment?
A scheme environment may often need to keep around call-stacks after
they are exited, because call-with-current-continuation can cause them
to be reentered again.
Similarly, you mention the problem with user-land threads, yet
specifically don't solve it (just handwave it a bit).
Likewise, what happens on table-blowout? You are using fixed-sized
tables, what happens when they fill up (and they WILL fill up.
Resources in a CPU should be 0, 1, or infinite, at least from the
user's point of view).
--
Nicholas C. Weaver nweaver@cs.berkeley.edu
