BugTraq
http://www.smashguard.org Jan 30 2004 11:34PM
Hilmi Ozdoganoglu (cyprian purdue edu) (2 replies)
Re: http://www.smashguard.org Feb 04 2004 05:26AM
Leon Harris (leon quoll com) (1 replies)
Re: http://www.smashguard.org Feb 05 2004 06:06PM
Seth Arnold (sarnold wirex com)
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 May 01 2004 01:56AM
Coleman Kane (cokane cokane org)
Re: http://www.smashguard.org May 01 2004 12:45AM
Theo de Raadt (deraadt cvs openbsd org)
Re: http://www.smashguard.org Apr 29 2004 11:24PM
Crispin Cowan (crispin immunix com) (2 replies)
Re: http://www.smashguard.org May 01 2004 12:28AM
Theo de Raadt (deraadt cvs openbsd org)
Re: http://www.smashguard.org Apr 29 2004 11:29PM
Pavel Machek (pavel ucw cz) (1 replies)
Re: http://www.smashguard.org May 01 2004 02:12AM
Nicholas Weaver (nweaver CS berkeley edu)
Re: http://www.smashguard.org Feb 10 2004 12:04AM
Theo de Raadt (deraadt cvs openbsd org)
Re: http://www.smashguard.org Feb 07 2004 06:11PM
Nicholas Weaver (nweaver CS berkeley edu)
Re: http://www.smashguard.org Feb 07 2004 03:27PM
Theo de Raadt (deraadt cvs openbsd org) (1 replies)
> The idea is not to create "custom CPUs" but to have our modification
> picked up by major vendors.

Er..

> 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).

Whoa, hold on. What these vendors are doing to their cpus is not on
the same scale as what you are suggesting.

In this regard, all AMD has added (to the amd64) is a per-page
non-executable bit. In PAE mode, bit 63 of the PTE becomes a NX bit.

This is not really all that new. sparc v8, sparc v9, alpha, and hppa
have had this for a very long time. The motorola 88k is also capable
of this, due to the split mmu handling. In general cpus like mips,
vax, m68k, and powerpc cpus are not capable of it. Some cpus with
split code & data tlb's are -- if they have software tlb load
mechanisms -- and some arm cpus fall into this catagory. But
performance can suffer significantly if the mechanims are poorly
designed.

Some operating systems make use of this. Such as OpenBSD, for ..
what.. 2 years now..

Now why is this not the same as yours? Even though we have an entire
operating system modified to operate with as many non-executable page
as possible, we still consider this a weaker protection mechanism than
gcc propolice. However these two very cheap mechanisms can work
together to improve resistance; fewer bugs can be exploited to control
flow.

By the way, I am pleased to say that my research has shown that the
AMD PAE NX bit will work in 32 bit mode. We are trying to make
modifications that will permit OpenBSD to use it.

[ reply ]
Re[2]: http://www.smashguard.org Feb 07 2004 08:58PM
Andrey Kolishak (andr sandy ru)
Re: http://www.smashguard.org Feb 03 2004 07:01PM
Nicholas Weaver (nweaver CS berkeley edu)


 

Privacy Statement
Copyright 2010, SecurityFocus