If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
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 |
#12
|
|||
|
|||
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 |
#13
|
|||
|
|||
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 |
#14
|
|||
|
|||
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(). |
#15
|
|||
|
|||
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 |
#16
|
|||
|
|||
"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 |
#17
|
|||
|
|||
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 |
#18
|
|||
|
|||
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 |
#19
|
|||
|
|||
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 |
#20
|
|||
|
|||
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 |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
HELP: P4C800-E Deluxe, Intel RAID and Windows detection problems | Michail Pappas | Asus Motherboards | 2 | November 20th 04 03:18 AM |
Intel developers helping out with Linux AMD64 | Yousuf Khan | Intel | 0 | December 17th 03 08:41 PM |
Intel Updates Plans Again: Adds Pentium 4 EE at 3.40GHz and Pentium 4 at 3.40GHz | lyon_wonder | General | 2 | November 10th 03 11:17 PM |
Intel | Commander | Intel | 0 | October 30th 03 07:05 PM |
Intel wants to slow down platform changes | Rob Stow | Intel | 0 | July 1st 03 05:29 PM |