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 |
#1
|
|||
|
|||
Why was Intel a no-show on No Execute?
Grumble wrote:
Yousuf Khan wrote: One thing he got partially wrong was his statement about Intel having no execute protection in the 16-bit segments. The feature was still there in the 32-bit segments, Intel never got rid of them. It was stupid OS designers who decided to ignore the feature that caused this problem. Are you calling them "stupid" because they opted for paging instead of segmentation, in an effort to write a portable OS? Do you think there should be an x86-specific Linux branch, using segmentation instead of paging? I don't think it would be so hard to put all the data in a data segment, and the code in a code segment, without overlapping them. It requires the CS: prefix on any loads from the code segment. Self modifying code is out of style these days, so that shouldn't be much of a problem. Now, for things like JIT where code is constantly being written while running some arrangement would need to be made. -- glen |
#2
|
|||
|
|||
In comp.arch Grumble wrote:
Yousuf Khan wrote: One thing he got partially wrong was his statement about Intel having no execute protection in the 16-bit segments. The feature was still there in the 32-bit segments, Intel never got rid of them. It was stupid OS designers who decided to ignore the feature that caused this problem. Are you calling them "stupid" because they opted for paging instead of segmentation, in an effort to write a portable OS? 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. -- Sander +++ Out of cheese error +++ |
#3
|
|||
|
|||
In comp.sys.ibm.pc.hardware.chips glen herrmannsfeldt wrote:
I don't think it would be so hard to put all the data in a data segment, and the code in a code segment, without overlapping them. It requires the CS: prefix on any loads from the code segment. Self modifying code is out of style these days, so that shouldn't be much of a problem. That _still_ won't help (never mind interpreted or JIT). If an attacker can redirect execution by modifying the return address on the stack, s/he doesn't need their own executable code. Just point to data like "/bin/sh" and return to an `exec` syscall. -- Robert |
#4
|
|||
|
|||
In comp.sys.ibm.pc.hardware.chips Robert Redelmeier wrote:
In comp.sys.ibm.pc.hardware.chips glen herrmannsfeldt wrote: I don't think it would be so hard to put all the data in a data segment, and the code in a code segment, without overlapping them. It requires the CS: prefix on any loads from the code segment. Self modifying code is out of style these days, so that shouldn't be much of a problem. That _still_ won't help (never mind interpreted or JIT). If an attacker can redirect execution by modifying the return address on the stack, s/he doesn't need their own executable code. Just point to data like "/bin/sh" and return to an `exec` syscall. Ah, but you make me think -- all current CPUs have an internal hardware call/return stack to speed up branch [mis]prediction. It would be relatively simple to check this hw stack against the memory stack and generate a fault if return addresses don't match. 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, but a mechanism could be made to except those few that do. A slightly bigger problem is the hw stacks are of limited depth (6?) and it might be possible to flood them out. But variable stack entry pointers would become more effective. -- Robert |
#5
|
|||
|
|||
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. Stefan |
#6
|
|||
|
|||
Grumble wrote:
Yousuf Khan wrote: One thing he got partially wrong was his statement about Intel having no execute protection in the 16-bit segments. The feature was still there in the 32-bit segments, Intel never got rid of them. It was stupid OS designers who decided to ignore the feature that caused this problem. Are you calling them "stupid" because they opted for paging instead of segmentation, in an effort to write a portable OS? No, for not opting to use both. There was no mutual exclusivity between paging and segmentation. Both could be used and complement each other. I think the original OS designers in their haste to port Unix to the new 32-bit Intel chip did a simple cross-compile, and then didn't bother to make use of any of the Intel-specific features of their architecture. They just left it at "good enough". Of course, using Intel features would've made them non-portable, but a lot of stuff gets non-portable at the lowest levels of the kernel anyways. Do you think there should be an x86-specific Linux branch, using segmentation instead of paging? There already was. The original pre-1.0 Linux kernels were using segments *and* paging. I think with addition of new people into the development team, Linux's original purpose got changed from being the ultimate Intel OS (Unix or otherwise), to being a free version of portable Unix. Yousuf Khan |
#7
|
|||
|
|||
Robert Redelmeier wrote:
That _still_ won't help (never mind interpreted or JIT). If an attacker can redirect execution by modifying the return address on the stack, s/he doesn't need their own executable code. Just point to data like "/bin/sh" and return to an `exec` syscall. How's an attacker to do that, when the the code, the stack and the heap don't even share the same memory addresses? Yousuf Khan |
#8
|
|||
|
|||
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. -- Robert |
#9
|
|||
|
|||
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 |
#10
|
|||
|
|||
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 |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Gigabyte GA-8IDML with mobile CPU? | Cuzman | Overclocking | 1 | December 8th 04 08:20 PM |
HELP: P4C800-E Deluxe, Intel RAID and Windows detection problems | Michail Pappas | Asus Motherboards | 2 | November 20th 04 03:18 AM |
P4EE will cost $1000 | Yousuf Khan | General | 60 | December 27th 03 02:19 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 |
IBM white paper on Opteron | Yousuf Khan | General | 115 | November 7th 03 03:04 AM |