Any comments on how useful it would be to have paged, segmented,
memory support for Pentium? I was thinking that by having separate
segments for text, stack, and heap, buffer overrun exploits would be
eliminated (I'm aware that this would require GCC patching as well).
Obviously, I'm thinking that I (and any similar fools I could rope
in) would try this (Probably delivering for a kernel at least a year out
of date by the time we had a patch).
Sorry
if this is too userspace.
On Sun, Jan 06, 2002 at 02:14:30PM +0000, Marcin Tustin wrote:
> Any comments on how useful it would be to have paged, segmented,
> memory support for Pentium? I was thinking that by having separate
> segments for text, stack, and heap, buffer overrun exploits would be
> eliminated (I'm aware that this would require GCC patching as well).
> Obviously, I'm thinking that I (and any similar fools I could rope
> in) would try this (Probably delivering for a kernel at least a year out
> of date by the time we had a patch).
It would break everything. Nowdays, Linux (and most OSes afaik) uses a
'flat' memory modell, well at least from the point of view of a process.
This will cause that you can address any part of process memory with a
single offset (it's another question that paging may deny some access). If
you create costum separated segments (with the right limit) for stack, code
and data, you won't address the address space of the process with a single
offset. You will also need segment registers to choose the right selector
which points to the descriptor table. Imho this would break almost anything.
And more: buffer overrun exploits WON'T BE eliminated entirely: let's
inmagine, that you have a char p[40]. If you don't check the data size eg
read to that place it will overwrite memory areas after p. Well, writing a
buffer overrun exploit may be harder but it would not be impossible. By the
way, non-executable stack kernel patches (like Solar Designer's one) made
the stack non-executable too, but that is not a whole solution as well, of
course (and see the problems of that kind of patches, eg gcc trampolines -
or whatever, I can't remember - and so on).
- Gabor
Even if you decided to come up with a whole new OS designed around it, along
with tools, you couldn't solve all your problems with this method.
Mainly, it is because of the limited number of segments you can have in a
process. And unless Intel extended the number of segments when they went
from the 286 to the 386, you would be limited to 8192 (16384) segments in a
process, way too few to make usable programs in this day and age. And once
you start combining data within segments, you have opened the door to buffer
overruns again.
>>
Any comments on how useful it would be to have paged, segmented,
memory support for Pentium? I was thinking that by having separate
segments for text, stack, and heap, buffer overrun exploits would be
eliminated (I'm aware that this would require GCC patching as well).
Obviously, I'm thinking that I (and any similar fools I could rope
in) would try this (Probably delivering for a kernel at least a year out
of date by the time we had a patch).
<<
On Sun, 6 Jan 2002 14:14:30 -0500, Marcin Tustin wrote
>
> Any comments on how useful it would be to have paged, segmented,
> memory support for Pentium? I was thinking that by having separate
> segments for text, stack, and heap, buffer overrun exploits would be
> eliminated (I'm aware that this would require GCC patching as well).
> Obviously, I'm thinking that I (and any similar fools I could rope
> in) would try this (Probably delivering for a kernel at least a year out
> of date by the time we had a patch).
Another solution would be to have two stacks. One for variable (auto data)
and one for program execution (call). Beside cache effect, this would provide
mostly the same performance as we get now. Just wondering if someone had
toyed with this idea.
---------------------------------------------------------
Jacques Gelinas <[email protected]>
vserver: run general purpose virtual servers on one box, full speed!
http://www.solucorp.qc.ca/miscprj/s_context.hc
On Monday, January 7, 2002, at 10:45 , Jacques Gelinas wrote:
> Another solution would be to have two stacks. One for variable
> (auto data)
> and one for program execution (call). Beside cache effect, this
> would provide
> mostly the same performance as we get now. Just wondering if
> someone had
> toyed with this idea.
A nice thing about two stacks is that it can be a completely
userspace thing. No need to involve the kernel at all; just gcc
and friends.
On Tue, Jan 08, 2002 at 02:17:14AM -0500, Anthony DeRobertis wrote:
>
> A nice thing about two stacks is that it can be a completely
> userspace thing. No need to involve the kernel at all; just gcc
> and friends.
Doesn't it have ABI implications as well?
If so, why not go all the way and have stacks grow upwards? :-)
Jeroen
On Tue, 8 Jan 2002 12:22:25 -0500, jtv wrote
> On Tue, Jan 08, 2002 at 02:17:14AM -0500, Anthony DeRobertis wrote:
> >
> > A nice thing about two stacks is that it can be a completely
> > userspace thing. No need to involve the kernel at all; just gcc
> > and friends.
>
> Doesn't it have ABI implications as well?
Yes, it might make the whole thing binary incompatible (so we could
have a new glibc major release :-) ) Not sure.
> If so, why not go all the way and have stacks grow upwards? :-)
This won't help. It will change the attack pattern though (so it may help
a bit). If the stack grow upward, then the data from the caller, passed to the
callee will be used to create the overflow. Taking control this way is still
possible.
And the stack grow direction is controlled by the CPU stack operation and
we can't change it.
---------------------------------------------------------
Jacques Gelinas <[email protected]>
vserver: run general purpose virtual servers on one box, full speed!
http://www.solucorp.qc.ca/miscprj/s_context.hc
jtv writes:
> On Tue, Jan 08, 2002 at 02:17:14AM -0500, Anthony DeRobertis wrote:
>>
>> A nice thing about two stacks is that it can be a completely
>> userspace thing. No need to involve the kernel at all; just gcc
>> and friends.
>
> Doesn't it have ABI implications as well?
On every architecture I'm familiar with. But that's a userland issue. I
don't believe the kernel cares how userland uses its stacks.
Change gcc. Recompile world. All should work, assuming your gcc changes are
bug-free, no one made assumptions about stack layout, no one wrote assembly
code, etc. [In other words, after 4 months of debugging you might get X
running again...]
>
> If so, why not go all the way and have stacks grow upwards? :-)
Some architectures have hardware assistance for downward growing stacks. One
example is 68K. I think x86 does too. OTOH, I don't think PPC does, though I
haven't read the Green Book recently.
Actually, if I were to be implementing split-stack, I'd probably have one
grow upward. Probably the data stack, because some architectures (68K, at
least) force the address stack to grow downwards.
Put an unmapped page between the two stacks, and all should be fine.
>
>
> Jeroen
>
On Tue, 8 Jan 2002, Anthony DeRobertis wrote:
> jtv writes:
>
> > On Tue, Jan 08, 2002 at 02:17:14AM -0500, Anthony DeRobertis wrote:
> >>
> >> A nice thing about two stacks is that it can be a completely
> >> userspace thing. No need to involve the kernel at all; just gcc
> >> and friends.
> >
> > Doesn't it have ABI implications as well?
>
> On every architecture I'm familiar with. But that's a userland issue. I
> don't believe the kernel cares how userland uses its stacks.
>
> Change gcc. Recompile world. All should work, assuming your gcc changes are
> bug-free, no one made assumptions about stack layout, no one wrote assembly
> code, etc. [In other words, after 4 months of debugging you might get X
> running again...]
>
> >
> > If so, why not go all the way and have stacks grow upwards? :-)
>
> Some architectures have hardware assistance for downward growing stacks. One
> example is 68K. I think x86 does too. OTOH, I don't think PPC does, though I
> haven't read the Green Book recently.
>
> Actually, if I were to be implementing split-stack, I'd probably have one
> grow upward. Probably the data stack, because some architectures (68K, at
> least) force the address stack to grow downwards.
>
> Put an unmapped page between the two stacks, and all should be fine.
At least with Intel ix8*, even though one can create a discriptor for
a (backwards) stack, you would have a hard time using it. 'Push' op-codes
decrement the stack-pointer and 'pop' increments it regardless of
the characteristics of the stack-selector. I don't know if this is
a bug or a feature.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
On Tue, Jan 08, 2002 at 02:05:09PM +0000, Anthony DeRobertis wrote:
>
> Change gcc. Recompile world. All should work, assuming your gcc changes are
> bug-free, no one made assumptions about stack layout, no one wrote assembly
> code, etc. [In other words, after 4 months of debugging you might get X
> running again...]
And, of course, the same for all other software. But for a highly secure
project, for instance, that might be worth it.
> Some architectures have hardware assistance for downward growing stacks. One
> example is 68K. I think x86 does too. OTOH, I don't think PPC does, though I
> haven't read the Green Book recently.
68K has predecrement/postincrement addressing modes (I'm not sure that
counts as "forcing" the stack to grow downwards); PPC has a symmetrical
load/store-with-update IIRC.
Jeroen
On Tuesday, January 8, 2002, at 12:11 PM, jtv wrote:
>
> And, of course, the same for all other software. But for a
> highly secure
> project, for instance, that might be worth it.
I'd imagine most things would just work. It's only going to be
the things that make assumptions about memory layout that will
break.
I picked X as an example because it cares quite a bit about
memory layout, especially when mapping in framebuffers and
whatnot.
>
> 68K has predecrement/postincrement addressing modes (I'm not sure that
> counts as "forcing" the stack to grow downwards);
The address stack on 68K grows downwards because JSR, BSR, etc.
do the stack manipulation for you.
Sure, you _could_ use JMP and BRA and maintain your own linkage,
but that'd take a large performance hit. Much larger than making
the data stack grow upwards, I dare say.
> PPC has a symmetrical
> load/store-with-update IIRC.
Right. I don't think it cares. Nice architecture ;-)
On Tuesday, January 8, 2002, at 09:14 AM, Richard B. Johnson wrote:
> At least with Intel ix8*, even though one can create a discriptor for
> a (backwards) stack, you would have a hard time using it.
> 'Push' op-codes
> decrement the stack-pointer and 'pop' increments it regardless of
> the characteristics of the stack-selector.
You'd have to do it manually, without those instructions. That's
what you get for using a CISC architecture from who-knows-when.
I'd guess most RISC architectures don't have this problem.
On Tue, 8 Jan 2002, Anthony DeRobertis wrote:
>
> On Tuesday, January 8, 2002, at 09:14 AM, Richard B. Johnson wrote:
>
> > At least with Intel ix8*, even though one can create a discriptor for
> > a (backwards) stack, you would have a hard time using it.
> > 'Push' op-codes
> > decrement the stack-pointer and 'pop' increments it regardless of
> > the characteristics of the stack-selector.
>
> You'd have to do it manually, without those instructions. That's
> what you get for using a CISC architecture from who-knows-when.
>
> I'd guess most RISC architectures don't have this problem.
>
Yes, and you can choose any one of a zillion registers to address
your "stack" although there are some de-facto standards, not enforced
by the hardware. But this all comes with trade-offs discussed from
about all perspectives in the past, context-switches come to mind.
Using Intel, with the proper call-frame on the stack, `iret` switches
context. Setting the proper call-frame and saved register values is
easy because there are so few registers!
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.