|
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 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).
>
Utter nonsense. Legacy software has to be recompiled to use the new CPU
instruction set. A new CPU architecture is vastly *more* intrusive than
a new compiler.
>The idea is not to create "custom CPUs" but to have our modification
>picked up by major vendors. Clearly there is interest in applying
>hardware to solve security issues based on the latest press releases
>from AMD that AMD chips include buffer-overflow protection (see
>Computer World, January 15, 2004).
>
As Theo said, the AMD buffer overflow "protection" is nothing more than
sensible separation of R and X bits per page, fixing a glaring and
anomalous defect in the original 386 MMU. Many CPUs before and since had
this feature, and it was just Intel slop in the early 1980s that
developed an MMU (and associated instruction set) that mistakenly
treated R and X per page as one bit.
Crispin
--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
CTO, Immunix http://immunix.com
Immunix 7.3 http://www.immunix.com/shop/
[ reply ]