[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bugtraq
Subject:    Re: BoS: Re: Smashing the stack
From:       Terry Lambert <terry () LAMBERT ! ORG>
Date:       1997-01-31 10:10:33
[Download RAW message or body]

> > My main question is if all
> > of these protection modes are available, why are they not being used
> > effectively in the OSs that exist for the X86 line?

[ ... TSS switching ... ]

This is a case of the Intel hardware engineers designing a chip without
talking to the software engineers that have to use it.

Specifically, it's difficult to do most of the interesting things
that you want to do to speed up switching between execution contexts
(you said it was slow.  In fact, it is unacceptably *s*l*o*w*).  For
instance, lazy FPU switching, SMP TLB shootdown, and page coloring.
You also have to deal (potentially) with register pipelining issues
on the newer processors (those which update the instruction cache
on self modification: P% and above)... expensive.


> > Wouldn't it be nice if you could write off stack smashing
> > on certain X86 platforms because the OS/processor combination wouldn't
> > allow it to occur?
>
> Yes.  It would also be nice if they took advantage of better memory-mapping
> techniques (like using a single 4MB page to map the non-swappable monolithic
> kernel image instead of multiple 4K pages) to improve performance by having
> a smaller TLB footprint, too.  It's on my todo list. ;)

It would be nicer if the processor architecture allowed arbitrary
protection domains.  Unsing Appendix F information, like 4M pages, is
a bad idea.  It is not a published interface, and Intel will not
necessarily continue to provide it in new chips.  Look at ICEBP and
the clone processors.

Barring that, the smaller the page size, the less boundry padding in
your executable, or the less boundry padding in your read interface.
It's my impression from a cursory look that Linux dual maps the page
on the text/data boundry from the executable.  This is no good, since
a modification of the data area prior to the mapped data area can in
fact damage code.  One can take advantage of this to modify an suid
executable's code without overflowing the stack.  Very bad.  I don't
see a nice way to implement protection domains with huge executables
wihtout forcing the data start to a page boundry... and for a 4M page,
well....


                                        Regards,
                                        Terry Lambert
                                        terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

[prev in list] [next in list] [prev in thread] [next in thread]