Re: [gentoo-hardened] simple PaX memory protection benchmark

On 14 Aug 2005 at 12:20, Pedro Venda wrote:
> > 2. you talk about preventing 'arbitrary privileges', but it's more
> >    about preventing exploitation of memory corruption bugs. the
> >    'arbitrary' part comes from the assumed ability attained by the
> >    attacker: arbitrary read/write access to the attacked process's
> >    memory.
>
> Agree. On the other hand, the exploits aim at doing something otherwise
> denied, hence the privileges reference. To be fixed also.

that's true, but it states more than what PaX actually does and
from past experience, people tend to mistunderstand too broad
descriptions and expect more than what's actually achieved (and
that is dangerous for them).

> > 4. some newer IA-32 CPUs do have NX support, but i haven't prepared
> >    PaX to use it yet (on amd64 in 64 bit mode it works of course).
>
> Never heard of them. Are those the newer Xeon with 64bit extensions?

well, it's kinda mixed thanks to Intel's infinite wisdom to
backport a mix of features into the IA-32 line. so you have
actually CPUs that have 64 bit support but no NX and also CPUs
without 64 bit support but with NX. at

  http://developer.intel.com/products/processor_number/info.htm

there's an up-to-date CPU chart that tells you which CPU supports
what exactly. as of this writing the URL is:

 http://developer.intel.com/products/processor_number/proc_info_table080905.pdf

hmm, actually looking at this table i can't find now a 64-bit
CPU without NX, but i have these memories that their initial
64 bit CPUs didn't have NX, maybe they were never actually sold...

> > 5. it's not the writable but the present (readable) bit that makes
> >    a page executable on IA-32.
>
> Yes, I've researched a bit and didn't get it clear. The bit we're talking here
> is the user/supervisor bit and it's the only one there, right?

depends on what you mean by 'here' ;-). if you mean the PAGEEXEC
logic, then it's indeed the user/supervisor bit that is used for
the executable bit, but if you mean what makes a page executable
without PAGEEXEC (and i believe the above statement was for that
case as you said: "These simpler MMUs overload one bit for WRITE/EXEC
permission settings, so every WRITEable page can also be EXECutable.")
then it's the present bit which makes a page both readable and
executable (and since a writable page has to be present (readable)
as well, it will be executable too, but that's just a sideeffect
of its being readable).

> After the page walk, if the bit is set for user, it get's cached
> in the TLB and becomes  readable/executable, right?

correct (readable/executable depending on which TLB gets filled by
the table walk).

> > 6. in general, instead of trying to reword the PaX docs, it's better
> >    to include the original, you'll avoid the interpretation mistakes
> >    that i'm in no mood to list here (it's being 2 AM and a performance
> >    test probably just doesn't need all this extra info anyway...).
>
> Please notice that I'm not rewording the official docs to make the text seem
> my own! If you'd like I'll add local references for specific docs.
> For the article's purpose, I wanted to give a small theoretical insight to
> justify the results. I'll review it and say something later.

i didn't mean to imply that you were making the PaX docs appear as
your own, just that if you wish to talk about PaX internals, then
either be correct and precise or just quote or link to the original.

and i still maintain that a performance test probably doesn't need
all these low-level implementation details, as the reader would then
also have to know IA-32 protected mode programming inside out...

-- 
gentoo-hardened@g.o mailing list