|
|
BugTraq
http://www.smashguard.org Jan 30 2004 11:34PM Hilmi Ozdoganoglu (cyprian purdue edu) (2 replies) RE: http://www.smashguard.org Feb 03 2004 12:36PM Dave Paris (dparis w3works com) (2 replies) RE: http://www.smashguard.org Feb 06 2004 08:29PM Hilmi Ozdoganoglu (cyprian purdue edu) (3 replies) Re: http://www.smashguard.org Feb 07 2004 11:44PM Crispin Cowan (crispin immunix com) (2 replies) Re: http://www.smashguard.org Apr 29 2004 09:55PM Pavel Machek (pavel ucw cz) (3 replies) Re: http://www.smashguard.org Apr 29 2004 11:24PM Crispin Cowan (crispin immunix com) (2 replies) Re: http://www.smashguard.org Feb 07 2004 03:27PM Theo de Raadt (deraadt cvs openbsd org) (1 replies) |
|
Privacy Statement |
>
> 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 (at) cs.berkeley (dot) edu [email concealed]
[ reply ]