bugtraq - Re: http://www.smashguard.org

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20040501015601.GA62792@blah>
Date: Sat, 1 May 2004 01:56:01 +0000
From: Coleman Kane <cokane@...ane.org>
To: Pavel Machek <pavel@....cz>
Cc: Crispin Cowan <crispin@...unix.com>,
	Hilmi Ozdoganoglu <cyprian@...due.edu>,
	Dave Paris <dparis@...orks.com>, bugtraq@...urityfocus.com
Subject: Re: http://www.smashguard.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

Content of type "application/pgp-signature" skipped