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)
IIRC, the "Buffer Overflow Protection" you refer to is simply the
NX page bit (MSB), right. This simply states that that page will
never be able to be loaded into an instruction register, basically
stating that if EIP is within that page, you get a Trap or Fault
of some sort.

This is more akin to making pages that can only have permissions:
rw- or r-- and no execute bit at all (there is also a R/RW flag on
pages as well).

This seperation does not really exist at the VM level on most of the
older x86 chips. Perhaps some of the PIII/PIV/and Xeons maybe? I don't
know about that, and sandpile.org seems to disagree with me.

Anyhow, if you use the memory segmentation features, there is a Readable
bit in the descriptor for a Code segment. This bit becomes the Writeable
bit in Data (non-executable) segments. The amd64 architecture seems to
have done away with this section of the x86's memory management, however.

So, in effect --x is possible under that scheme, but is not supported in
amd64's long-mode. --x is supported under current x86 tech., but I think
it would require a humongous rewrite to a non-flat memory model for
the vast majority of OS's that run under x86. The amd64 phase-out of it
is also probably a nail in the coffin on this one. Perhaps having distinct
R/W/X perms on page table entries would be helpful here. Since the systems
only really had a concept of Read/Write memory, historically, at the VM
level, it may not "make sense" to the processor to address memory which
cannot be readable. How else would it actually be able to run the Fetch
to latch in new instructions. Perhaps a "Non-Loadable" bit would make
more sense.

On Thu, Apr 29, 2004 at 11:55:07PM +0200, Pavel Machek wrote, and it was proclaimed:
> Hi!
>
> > >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
>
> Actually it is not "sensible", and it is not separation.
>
> You can have r--, r-x, but you can't have --x.
> Pavel
> --
> 934a471f20d6580d5aad759bf0d97ddc

[ reply ]
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)
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