|
|
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 Feb 07 2004 03:27PM Theo de Raadt (deraadt cvs openbsd org) (1 replies) |
|
Privacy Statement |
> >>>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
> >>
> >>
> >
> >Actually it is not "sensible", and it is not separation.
> >
> >You can have r--, r-x, but you can't have --x.
> >
> >
> But that is *exactly* what is meant by "separation" of R and X.
>
> I have no idea what you mean by it not being "sensible". Most every CPU
> I have ever seen does this except the x86. Someone apparently thought
> there was no value in separate R and X bits for the i386 back in the
> mid-80s. It was a false economy :)
Well.. they are not really separate bits.
If they was, you'd have ---, --x, r--, r-x. You can't have --x
combination (which is sad for the emulators).
I believe that on most sane architectures (m68k at least), you can
have all 4 combinations.
Pavel
--
934a471f20d6580d5aad759bf0d97ddc
[ reply ]