flat assembler
Message board for the users of flat assembler.

Index > Main > CPU behaviour under over repetition of prefixes

Author
Thread Post new topic Reply to topic
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 23 Apr 2009, 15:18
I just was experimenting with this and found these results

Code:
format pe gui 4.0
times 13 ds
mov eax, eax
int3    

Result: Exception 0x80000003 (OK, int3 reached)

Code:
format pe gui 4.0
times 14 ds
mov eax, eax
int3    

Result: Access violation when reading [FFFFFFFF]

Code:
format pe gui 4.0
times 15 ds
mov eax, eax
int3    

Result: Illegal instruction

Does your CPU the same thing? It is clearly documented that this will happen?

PS: I mean better than "The result of using multiple prefixes from a single group is unpredictable.". Also, I mean any documentation, not just official.
Post 23 Apr 2009, 15:18
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20299
Location: In your JS exploiting you and your system
revolution 23 Apr 2009, 15:42
You are not allowed to have an instruction longer than 15 bytes. It is clearly documented. But the error may have confused the OS. I would have expected illegal instruction. I'll check the manuals later to see what they have said over the years.
Post 23 Apr 2009, 15:42
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20299
Location: In your JS exploiting you and your system
revolution 23 Apr 2009, 15:53
All these non-normal things tend to generate int13 (GP) exceptions, so the access violation being reported is also handled by the int13 handler.
IA32 ref (TFM) wrote:
Interrupt 13—General Protection Exception (#GP)

Exception Class: Fault.

Description: Indicates that the processor detected one of a class of protection violations called "general-protection violations." The conditions that cause this exception to be generated comprise all the protection violations that do not cause other exceptions to be generated (such as, invalid-TSS, segment-not-present, stack-fault, or page-fault exceptions). The following conditions cause general-protection exceptions to be generated:
  • Exceeding the segment limit when accessing the CS, DS, ES, FS, or GS segments.
  • Exceeding the segment limit when referencing a descriptor table (except during a task switch or a stack switch).
  • Transferring execution to a segment that is not executable.
  • Writing to a code segment or a read-only data segment.
  • Reading from an execute-only code segment.
  • Loading the SS register with a segment selector for a read-only segment (unless the selector comes from a TSS during a task switch, in which case an invalid-TSS exception occurs).
  • Loading the SS, DS, ES, FS, or GS register with a segment selector for a system segment.
  • Loading the DS, ES, FS, or GS register with a segment selector for an execute-only code segment.
  • Loading the SS register with the segment selector of an executable segment or a null segment selector.
  • Loading the CS register with a segment selector for a data segment or a null segment selector.
  • Accessing memory using the DS, ES, FS, or GS register when it contains a null segment selector.
  • Switching to a busy task during a call or jump to a TSS.
  • Using a segment selector on a non-IRET task switch that points to a TSS descriptor in the current LDT. TSS descriptors can only reside in the GDT. This condition causes a #TS exception during an IRET task switch.
  • Violating any of the privilege rules described in Chapter 4, "Protection."
  • Exceeding the instruction length limit of 15 bytes (this only can occur when redundant prefixes are placed before an instruction).
  • Loading the CR0 register with a set PG flag (paging enabled) and a clear PE flag (protection disabled).
  • Loading the CR0 register with a set NW flag and a clear CD flag.
  • Referencing an entry in the IDT (following an interrupt or exception) that is not an interrupt, trap, or task gate.
  • Attempting to access an interrupt or exception handler through an interrupt or trap gate from virtual-8086 mode when the handler’s code segment DPL is greater than 0.
  • Attempting to write a 1 into a reserved bit of CR4.
  • Attempting to execute a privileged instruction when the CPL is not equal to 0 (see Section 4.9, “Privileged Instructions,” for a list of privileged instructions).
  • Writing to a reserved bit in an MSR.
  • Accessing a gate that contains a null segment selector.
  • Executing the INT n instruction when the CPL is greater than the DPL of the referenced interrupt, trap, or task gate.
  • The segment selector in a call, interrupt, or trap gate does not point to a code segment.
  • The segment selector operand in the LLDT instruction is a local type (TI flag is set) or does not point to a segment descriptor of the LDT type.
  • The segment selector operand in the LTR instruction is local or points to a TSS that is not available.
  • The target code-segment selector for a call, jump, or return is null.
  • If the PAE and/or PSE flag in control register CR4 is set and the processor detects any reserved bits in a page-directory-pointer-table entry set to 1. These bits are checked during a write to control registers CR0, CR3, or CR4 that causes a reloading of the page-directory-pointer-table entry.
  • Attempting to write a non-zero value into the reserved bits of the MXCSR register.
  • Executing an SSE/SSE2/SSE3 instruction that attempts to access a 128-bit memory location that is not aligned on a 16-byte boundary when the instruction requires 16-byte alignment. This condition also applies to the stack segment.
Post 23 Apr 2009, 15:53
View user's profile Send private message Visit poster's website Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2139
Location: Estonia
Madis731 23 Apr 2009, 16:43
I will get an access violation every time I cross this 15-byte boundary on my 64-bit system (according to FDGB). Nothing weird about the results.
Post 23 Apr 2009, 16:43
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 23 Apr 2009, 17:11
OK Smile
Post 23 Apr 2009, 17:11
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20299
Location: In your JS exploiting you and your system
revolution 24 Apr 2009, 12:34
I get the same results as LocoDelAssembly: access violation and then illegal instruction.

CPU: Pentium M (Banias)
OS: WinXP SP2
Post 24 Apr 2009, 12:34
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.