Why was Intel a no-show on No Execute?

In comp.sys.ibm.pc.hardware.chips Stefan Monnier wrote:
It would be relatively simple to check this hw stack against
the memory stack and generate a fault if return addresses
don't match.

Lookup "call-with-current-continuation" to see why this is not a good idea.
Or maybe just think of how to implement exception handling.

Exception handling is easy -- mismatch produces a MC interrupt.
The kernelspace ISR checks the MSRs which tell it that a return
addr mismatch occurred. Kenel decides what to do -- abort proc,
log, or proceed.

Sure it'll be slow, but how often are calls not paired with
returns? call jtable[eax*4] is the standard syntax for a
jump table, not `push eax/ret`

-- Robert

Robert Redelmeier wrote:
In comp.sys.ibm.pc.hardware.chips Yousuf Khan
wrote:
How's an attacker to do that, when the the code, the stack and the
heap don't even share the same memory addresses?

Easy. Overwrite the stack with crafted input to an unrestricted
input call (getch() is a frequent culprit). This is the basic
buffer overflow.

In the location for the return address (where EBP is usually
pointing), put in a return address that points to a suitably
dangerous part of the existing code. Like an `exec` syscall.
Above this return address, put in data to make that syscall
nefarious.

Nope, won't work. Segmentation would protect it completely. There is no way
for data written to the heap to touch the data in the stack. Stack segment
and data segment are separate. It's like as if the stack had its own
container, the code has its own, and the data heap its own. What happens in
one container won't even reach the other containers.

Face it, segments were the perfect security mechanism, and systems
developers completely ignored it!

Yousuf Khan

Sander Vesik wrote:
Do you think there should be an x86-specific Linux branch,
using segmentation instead of paging?


There was one for quite a while for pre-386 modes/machines.

That was Minix. Linux has always been for 386 and later machines only.

Yousuf Khan

Robert Redelmeier wrote:

Overwrite the stack with crafted input to an unrestricted
input call (getch() is a frequent culprit).

There is no getch() in ISO C.

fgetc(), getc(), and getchar() return a single character.

Perhaps you meant gets().

Robert Redelmeier wrote:

Ah, but you make me think -- all current CPUs have an internal
hardware call/return stack to speed up branch [mis]prediction.

e.g. the Athlon implements a 12-entry return address stack to
predict return addresses from a near or far call. As CALLs are
fetched, the next EIP is pushed onto the return stack. Subsequent
RETs pop a predicted return address off the top of the stack.

It would be relatively simple to check this hw stack against
the memory stack and generate a fault if return addresses
don't match.

I think you've just killed the performance of recursive functions.

This could be enabled by a bit in the MSR if the OS has support
to handle/log "return addr faults". Most pgms should never
generate a return fault

This is where I think you are wrong.

The K8 has a counter to measure this event:

88h IC Return stack hit
89h IC Return stack overflow

It would be interesting to take, say, SPEC CPU2000, and count
the number of overflows for each benchmark. I might try.

--
Regards, Grumble

"YK" == Yousuf Khan writes:

YK That was Minix. Linux has always been for 386 and later machines
YK only.

I think the ELKS people will be saddened to hear that.


/Benny

Grumble writes:

It would be relatively simple to check this hw stack against
the memory stack and generate a fault if return addresses
don't match.

I think you've just killed the performance of recursive functions.

And possibly longjmp()/setcontext() and the like; quite a bit of
additional work is needed to fix all such things (and if you want to
throw in binary compatibility, it's going to be harder still.

Casper

In comp.sys.ibm.pc.hardware.chips Grumble wrote:
I think you've just killed the performance of recursive functions.

I don't think so. For a recursive function there are many
calls, possibly flooding out the hw return stack. But every
call has a return, and that address _is_ correct on both the
hw and memory stacks.

88h IC Return stack hit
89h IC Return stack overflow

It would be interesting to take, say, SPEC CPU2000, and count
the number of overflows for each benchmark. I might try.

Excellent! I do not suggest trapping out overflows.
They're to occur on deep recursion which should not contain
evil getch() calls. Just trap misses.

-- Robert

In comp.sys.ibm.pc.hardware.chips Grumble wrote:
There is no getch() in ISO C.
Perhaps you meant gets().

Thank you for the correction. I do mean gets().
I apologize for any confusion.

-- Robert

In comp.sys.ibm.pc.hardware.chips Yousuf Khan wrote:
Nope, won't work. Segmentation would protect it completely. There is no way
for data written to the heap to touch the data in the stack. Stack segment
and data segment are separate. It's like as if the stack had its own
container, the code has its own, and the data heap its own. What happens in
one container won't even reach the other containers.

True in a literal sense.

But `c` compilers have this habit of allocating local variable
space on the stack. So when `char input[80];` is coded in a
routine, ESP gets decreased by 80 and that array is sitting
just below the return address!

I don't think it's _required_ by any standard that local vars are
allocated on the stack, but it sure makes memory managment easy.

AFAIK, only global vars and large malloc()s are put on the heap.

-- Robert