Re[2]: http://www.smashguard.org

[Andrey Kolishak]

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

you are pleased? your research ?!

you should be aware of fact that feature implemented by Microsoft for
XP which is in beta yet but announced for several months already.

"The 32-bit version of Windows currently leverages the NX processor
feature, as defined by the AMD64 Architecture Programmer's Manual.
This processor feature requires the processor run in Physical Address Extension (PAE) mode."

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwxp/html/securityinxpsp2.asp

Best regards,
Andrey


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

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

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

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

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

[Theo de Raadt]

> 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
> anomalous defect in the original 386 MMU. Many CPUs before and since had
> this feature, and it was just Intel slop in the early 1980s that
> developed an MMU (and associated instruction set) that mistakenly
> treated R and X per page as one bit.

It's going to get worse before it gets better.

At the same time that AMD is per-page X bit support to the x86
architecture, Intel is removing such capability from ARM cpus. And of
course mips cpus cannot do it. And it will be ages before x86
compatible cpus like the NSC Geode and such will have it.

So pretty much any low-power embedded device you can buy in the future
will not have such basic and simple protection.

Per-page execute permission functionality in a modern split-TLB CPU is
about 80 gates. On a non-split TLB it adds perhaps 80 gates + 20-per
line.

[Crispin Cowan]

Pavel Machek wrote:

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

Crispin

--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
CTO, Immunix http://immunix.com
Immunix 7.3 http://www.immunix.com/shop/

[Pavel Machek]

Hi!

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

[Pavel Machek]

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

[Theo de Raadt]

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

Most very cpu except x86? You are wrong. Let's see:

Does not have a way to do per-page executability control:

i386
powerpc
arm mips

vax m68k sparcv7 (and a few legacy....)

Lets see... that would be every desktop machine, and every Cisco
router... and every WindowsCE device, and every PalmOS machine.. and
every cell phone...

Contrast this to the processors that have a way to do it:

m88k amd29k sparcv8 sparcv9 ia64 amd64 alpha hppa

What is that.... a list of the more rare processors?

So it sure seems to me that what most people have on their desks
does not have a way to do per-page X bits. It is not just x86 --
it is everything in use today.

Interestingly, by using the x86 segment registers in an ugly way
we come up with a hack that lets us do it on the x86 machines, but
the other major cpu players utterly lack a way to do this. Forget
about protecting your Mac or your Cisco or your handheld against
buggy code.

[Nicholas Weaver]

On Fri, Apr 30, 2004 at 01:29:21AM +0200, Pavel Machek composed:
> 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.

Silly confusion time:

The key is good separation of WRITE and EXECUTE. Far too many CPUs
don't have separate TLB bits for writeable and executable.


--
Nicholas C. Weaver nweaver@cs.berkeley.edu

[Coleman Kane]

--2fHTh5uZTiUOsy+g
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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=20
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 pr=
oclaimed:
> Hi!
>=20
> > >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=
=20
> > sensible separation of R and X bits per page, fixing a glaring and=20
>=20
> Actually it is not "sensible", and it is not separation.
>=20
> You can have r--, r-x, but you can't have --x.
> Pavel
> --=20
> 934a471f20d6580d5aad759bf0d97ddc

--2fHTh5uZTiUOsy+g
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)

iD8DBQFAkwOw/eUc+MkM8EkRAutnAJwP6RbRNMVKy9L9+pwp3nayZrxusQCdHmv U
TSGzwJQW35VOd3vzOXKSpZQ=
=iPmW
-----END PGP SIGNATURE-----

--2fHTh5uZTiUOsy+g--

[Theo de Raadt]

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

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