Re: Cross-Modifying Code

From: Matt Taylor (para_at_tampabay.rr.com)
Date: 05/14/04 

Date: Fri, 14 May 2004 03:36:05 +0000 (UTC)

"Alex McDonald" <alex_mcd@btopenworld.com> wrote in message
news:c8119q$cbo$1@titan.btinternet.com...
> "Matt Taylor" <para@tampabay.rr.com> wrote in message
> news:S3Poc.609486$Po1.600590@twister.tampabay.rr.com...
> > I was reading in the IA-32 System Programming Guide (Vol. 3) in Ch. 7
> about
> > handling of cross-modifying code, and Intel warns against modifying code
> > that may be executing in another processor. I'm working on some code
which
> > cross-modifies, although I don't really care about synchronization. I
was
> > wondering if anybody could clarify on their warning.
> >
> > If I modified the displacement part of a jmp/call instruction, would the
> > processor branch only to the original address or to the newly written
> > address? I am updating with lock, but the docs hint in 7.1.2.2 that
> > instruction fetch supercedes lock, so I'm thinking that an unaligned
> branch
> > target could cause a race. This still raises another question: are there
> > still caveats even if the branch target is aligned and updated
atomically?
> >
> > -Matt
> >
>
> There's an explicit warning that instruction fetch and page table accesses
> don't honour LOCKed instructions, as you note. There's an implication they
> don't honour xFENCE for prefetched code either. CPUID or some other xFENCE
> would appear to need to be temporally executed (that is, after the
> modification) on the _other_ MP to ensure consistency. My reading has
either
> the old instruction or the new executed, depending on what's in the
> instruction pipeline. Without a lock (the example given uses a spin lock)
> then you don't know when to issue the CPUID.
>
> However, if you can get the processor to pass through a CPUID on its way
to
> your instruction, that might do. In other words;
>
> CPUID
> JMP xxxx
>
> where xxxx is the modified address, and the processor can't get to the
jump
> except through the CPUID (or an xFENCE might suffice). Would make the code
> slow though, especially if the jump is frequently taken and infrequently
> modified.
>
> Does a hyperthreaded processor suffer from the same issue? Or AMDs?

The Opteron manuals don't comment on the interaction between executing code
and locked updates. However, I would presume that the processor would
invalidate the caches in other processors before the update proceeded. I
would expect a Hyperthreaded processor to treat cross-modifying code between
logical processors the same way it treats self-modifying code since both
logical processors share the caches.

As long as instruction fetch can't violate the atomic nature of a locked
update even when unaligned, then I'm unconcerned with the note in the
manual.

-Matt

Relevant Pages

  • Re: Cross-Modifying Code
    ... > that may be executing in another processor. ... > If I modified the displacement part of a jmp/call instruction, ... > instruction fetch supercedes lock, so I'm thinking that an unaligned ... then you don't know when to issue the CPUID. ...
    (comp.lang.asm.x86)
  • Re: More performance tests of different AES implementations
    ... > 1) Executing the cpuid instruction is undesirable, ... I am not sure about this since, without it, the rdtsc instruction can be ... Intel's code timing examples use cpuid before rdtsc so I am reluctant to ... much x86 cycle counter timing code does leave this out ...
    (sci.crypt)
  • Re: Cross-Modifying Code
    ... >> the old instruction or the new executed, ... >> then you don't know when to issue the CPUID. ... > The Opteron manuals don't comment on the interaction between executing ... > As long as instruction fetch can't violate the atomic nature of a locked ...
    (comp.lang.asm.x86)
  • Re: [RFC, PATCH 1/24] i386 Vmi documentation
    ... + capabilities is to provide notification of these feature through ... How should that work since CPUID cannot be intercepted by ... So how would your Hypervisor detect a kernel hung with interrupts ... A subtle trap is also that it will do so on the next instruction, ...
    (Linux-Kernel)
  • Re: unset($this) or maybe unset(&$this)
    ... which does not involve a jump is executed the next instruction to be executed will be the very next instruction in the same object method. ... The code may still exist in the class definition, but the object, which contains a copy of that code in memory, does not, so how can it continue executing any of that code? ... When you call something like obj.Func; in C++ (assuming obj is an instance of class Foo), the compiler actually translates that to something like: ...
    (comp.lang.php)