WinXP SP2 developer's implications
-
That memory protection thing is IMO a good idea. I think that should have been done a while back. ;) besmel wrote: mmmmhhhhh...... :confused:
**"It is impossible to rightly govern the world without God and the Bible." -- George Washington
-
Additionally, Microsoft is working with microprocessor companies to help Windows support hardware-enforced "no execute" (or NX) on microprocessors that contain the feature About time, kids, about time.
"Vierteile den, der sie Hure schimpft mit einem türkischen Säbel."
mlog || Agile Programming | doxygen -
That memory protection thing is IMO a good idea. I think that should have been done a while back. ;) besmel wrote: mmmmhhhhh...... :confused:
**"It is impossible to rightly govern the world without God and the Bible." -- George Washington
I agree, but... I'm just thinking on all the implications these changes will bring to support teams : I see already some support justify their problems since the WinXP SP2 has been installed.... This is a general consideration : should a SP bring this whole bag of changes or should it just fix bugs ? I'd prefere a SP just resolving bugs and eventually a new package called 'Security Pack for WinXP' or 'Security Technical Refresh for WinXP' or whatever This SP2 is gonna brake a lot of working stuff IMHO that's why I'm puzzling... :confused:
-
Strangely enough I always thought code segments on the x86 architecture (at least from the 286 onwards) were non writeable. And I must have assumed (I'm talking ten or more years ago) that the converse applied, that data segments were non executable. Rob Manderson http://www.mindprobes.net "I killed him dead cuz he was stepping on my turf, cutting me out of my bling the same way my ho cuts cookies, officer" "Alright then, move along" - Ian Darling, The Lounge, Oct 10 2003
-
Strangely enough I always thought code segments on the x86 architecture (at least from the 286 onwards) were non writeable. And I must have assumed (I'm talking ten or more years ago) that the converse applied, that data segments were non executable. Rob Manderson http://www.mindprobes.net "I killed him dead cuz he was stepping on my turf, cutting me out of my bling the same way my ho cuts cookies, officer" "Alright then, move along" - Ian Darling, The Lounge, Oct 10 2003
Oh well, time for my fourth try - try 1 was a letter to The Inquirer about six months ago; you can find tries 2 and 3 at Chris Brumme's blog[^] (comment 13 of 26) and Raymond Chen's blog[^] (comments 8 and 12 of 14). On x86, only code addressed through the code segment can be executed. However, in Windows' flat memory model, the segment initially assigned to the CS register has a base address of 0 and a size of 4GB - you can address all the memory through this segment. Technically, it's the segment descriptors themselves (the value loaded into the segment selector register is an offset in the descriptor table) which tell the processor whether an assignment to a segment register is permissible. A segment can be marked in any combination of read, write and execute. Loading a segment register with a segment with invalid permissions for that register (e.g. loading CS with a writable segment or a non-executable segment) causes an access violation exception. Data accesses are generally performed through the DS segment, unless the instruction is prefixed by a segment-selector byte redirecting through a different segment register. String operations (MOVS, CMPS) use ES for the destination (IIRC). Stack operations (PUSH, POP) take place through SS. When a data access takes place, the address referenced is segment base + address offset. Windows XP basically ignores segment protections and hence sets DS, ES and SS to the same selector (offset 0023) which is a data--type segment, has an offset of 0 and length 4GB, and is read/write. CS is set to 001b, which is a code-type segment, offset 0, length 4GB, read/execute. Use the
dgcommand in WinDBG to inspect segment selectors. The segment pointed to by FS is special in Win32: it points to the Thread Information Block (sometimes referred to as the Thread Environment Block). The value of FS is different for each thread, but the primary thread's selector has a base of 7ffde000 and a length of 4KB. It's a read/write data segment. This allows each thread to refer to its own -
Oh well, time for my fourth try - try 1 was a letter to The Inquirer about six months ago; you can find tries 2 and 3 at Chris Brumme's blog[^] (comment 13 of 26) and Raymond Chen's blog[^] (comments 8 and 12 of 14). On x86, only code addressed through the code segment can be executed. However, in Windows' flat memory model, the segment initially assigned to the CS register has a base address of 0 and a size of 4GB - you can address all the memory through this segment. Technically, it's the segment descriptors themselves (the value loaded into the segment selector register is an offset in the descriptor table) which tell the processor whether an assignment to a segment register is permissible. A segment can be marked in any combination of read, write and execute. Loading a segment register with a segment with invalid permissions for that register (e.g. loading CS with a writable segment or a non-executable segment) causes an access violation exception. Data accesses are generally performed through the DS segment, unless the instruction is prefixed by a segment-selector byte redirecting through a different segment register. String operations (MOVS, CMPS) use ES for the destination (IIRC). Stack operations (PUSH, POP) take place through SS. When a data access takes place, the address referenced is segment base + address offset. Windows XP basically ignores segment protections and hence sets DS, ES and SS to the same selector (offset 0023) which is a data--type segment, has an offset of 0 and length 4GB, and is read/write. CS is set to 001b, which is a code-type segment, offset 0, length 4GB, read/execute. Use the
dgcommand in WinDBG to inspect segment selectors. The segment pointed to by FS is special in Win32: it points to the Thread Information Block (sometimes referred to as the Thread Environment Block). The value of FS is different for each thread, but the primary thread's selector has a base of 7ffde000 and a length of 4KB. It's a read/write data segment. This allows each thread to refer to its ownWhat we really need is a :slapforehead: icon :) Of course it all makes sense when the flat memory model is used. Back in 1993 I wrote a device driver whose sole purpose in life was to patch the Invalid Exception handler in Microsoft OS/2 (yes, Microsoft OS/2) so that if we reached the then equivalent of a BSOD the machine would reboot (OS/2 would just sit there at that point and possibly wait overnight until someone came in the next day and noticed). I recall having to change the segment selector for the page I needed to patch from a code segment to a data segment, make the patch and then change it back to a code selector. I also vividly recall having to painfully explain to my boss why all that strange looking assembler code was present in the driver and why it had to do something that was almost immediately reversed. His PHd in Computer Science hadn't equippped him to understand the reality of coding for the 286 :) Of course this was on a 16 bit os using 64K segments and I hadn't noticed the radical change to 32 bit os's with flat 4gb memory segments all mapped to the same physical memory. I suppose that's what happens when you step away from assembler and learn MFC instead :) So thanks for the explanation :) [edit]Oh, you got my 5![/edit] Rob Manderson http://www.mindprobes.net "I killed him dead cuz he was stepping on my turf, cutting me out of my bling the same way my ho cuts cookies, officer" "Alright then, move along" - Ian Darling, The Lounge, Oct 10 2003
-
What we really need is a :slapforehead: icon :) Of course it all makes sense when the flat memory model is used. Back in 1993 I wrote a device driver whose sole purpose in life was to patch the Invalid Exception handler in Microsoft OS/2 (yes, Microsoft OS/2) so that if we reached the then equivalent of a BSOD the machine would reboot (OS/2 would just sit there at that point and possibly wait overnight until someone came in the next day and noticed). I recall having to change the segment selector for the page I needed to patch from a code segment to a data segment, make the patch and then change it back to a code selector. I also vividly recall having to painfully explain to my boss why all that strange looking assembler code was present in the driver and why it had to do something that was almost immediately reversed. His PHd in Computer Science hadn't equippped him to understand the reality of coding for the 286 :) Of course this was on a 16 bit os using 64K segments and I hadn't noticed the radical change to 32 bit os's with flat 4gb memory segments all mapped to the same physical memory. I suppose that's what happens when you step away from assembler and learn MFC instead :) So thanks for the explanation :) [edit]Oh, you got my 5![/edit] Rob Manderson http://www.mindprobes.net "I killed him dead cuz he was stepping on my turf, cutting me out of my bling the same way my ho cuts cookies, officer" "Alright then, move along" - Ian Darling, The Lounge, Oct 10 2003
Rob Manderson wrote: What we really need is a :slapforehead: icon Of course it all makes sense when the flat memory model is used. We do! :doh: ( : doh : ). Obviously without the spaces... Iain.
-
Rob Manderson wrote: What we really need is a :slapforehead: icon Of course it all makes sense when the flat memory model is used. We do! :doh: ( : doh : ). Obviously without the spaces... Iain.
Nowhere near expressive enough!! I want an icon that expresses that feeling of 'omg I've been truly stupid and blind'! :) Rob Manderson http://www.mindprobes.net "I killed him dead cuz he was stepping on my turf, cutting me out of my bling the same way my ho cuts cookies, officer" "Alright then, move along" - Ian Darling, The Lounge, Oct 10 2003
-
What we really need is a :slapforehead: icon :) Of course it all makes sense when the flat memory model is used. Back in 1993 I wrote a device driver whose sole purpose in life was to patch the Invalid Exception handler in Microsoft OS/2 (yes, Microsoft OS/2) so that if we reached the then equivalent of a BSOD the machine would reboot (OS/2 would just sit there at that point and possibly wait overnight until someone came in the next day and noticed). I recall having to change the segment selector for the page I needed to patch from a code segment to a data segment, make the patch and then change it back to a code selector. I also vividly recall having to painfully explain to my boss why all that strange looking assembler code was present in the driver and why it had to do something that was almost immediately reversed. His PHd in Computer Science hadn't equippped him to understand the reality of coding for the 286 :) Of course this was on a 16 bit os using 64K segments and I hadn't noticed the radical change to 32 bit os's with flat 4gb memory segments all mapped to the same physical memory. I suppose that's what happens when you step away from assembler and learn MFC instead :) So thanks for the explanation :) [edit]Oh, you got my 5![/edit] Rob Manderson http://www.mindprobes.net "I killed him dead cuz he was stepping on my turf, cutting me out of my bling the same way my ho cuts cookies, officer" "Alright then, move along" - Ian Darling, The Lounge, Oct 10 2003
Rob Manderson wrote: I hadn't noticed the radical change to 32 bit os's with flat 4gb memory segments all mapped to the same physical memory. Just a quick note: it's segment:offset -> virtual address -> physical address in the 386 memory model. A major reason that Win32 ignores the segment registers is simply that no other processor architecture has them, and NT was originally designed to be portable to different architectures. The FS use is an aberration, but then so is stack-based exception handling - all other NT-supported architectures (once and future - MIPS, PowerPC, Alpha, Itanium, AMD64 in long mode) use table-based exceptions. Did OS/2 use stack-based exception handlers, or is this just an oddity of the original NT implementation?
-
Rob Manderson wrote: I hadn't noticed the radical change to 32 bit os's with flat 4gb memory segments all mapped to the same physical memory. Just a quick note: it's segment:offset -> virtual address -> physical address in the 386 memory model. A major reason that Win32 ignores the segment registers is simply that no other processor architecture has them, and NT was originally designed to be portable to different architectures. The FS use is an aberration, but then so is stack-based exception handling - all other NT-supported architectures (once and future - MIPS, PowerPC, Alpha, Itanium, AMD64 in long mode) use table-based exceptions. Did OS/2 use stack-based exception handlers, or is this just an oddity of the original NT implementation?
Mike Dimmick wrote: Did OS/2 use stack-based exception handlers, or is this just an oddity of the original NT implementation? As far as I recall (and bear in mind that all my experience was on Microsoft OS/2 which stopped at version 1.3 or thereabouts (released in early 1991?)) there was was no concept of application level exception handlers at all. If there were I certainly didn't run across them but then again, I was writing kernel mode device drivers at the time and not doing PM programming. Mike Dimmick wrote: A major reason that Win32 ignores the segment registers is simply that no other processor architecture has them, and NT was originally designed to be portable to different architectures You make a good point and one that we're apt to forget these days. Yes there was once a time when NT would run on hardware other than x86 based, and it was planned that successor operating systems would also run on such hardware. Reading that line back it sounds sarcastic but I didn't mean it that way. The market spoke. Rob Manderson http://www.mindprobes.net "I killed him dead cuz he was stepping on my turf, cutting me out of my bling the same way my ho cuts cookies, officer" "Alright then, move along" - Ian Darling, The Lounge, Oct 10 2003