|
|
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 |
> > >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
>
> Actually it is not "sensible", and it is not separation.
>
> You can have r--, r-x, but you can't have --x.
Oh for the record. A few chips make it possible to have --x
permissions.
alpha (I am not positive)
sparc64 (I am not positive)
ia64
hppa
amd29k
m88k
The first two have software tlb refillers with a split tlb architecture,
but I am not sure if there is tlb "leak"
The next three have specific page table bits for kernel (r w x) and
user (r w x).
The last has a harvard-style split mmu (entirely different mmu for
code and data), and it should be possible to play games to do it...
[ reply ]