OSDev.org

Poking at some weird things, figured this might be a good place to ask.

Suppose code running on one core, wanted to change RIP (longjmp) on another core.

Is there a direct way to do that? /proc/kallsyms on Linux has a bunch of interesting stuff in low memory, is anything like a memory map of registers? I can imagine poking interrupt vectors but I'm wondering if there's something not quite so passive.

Alternatively, suppose RIP was sitting on a HLT instruction in main memory. If I just rewrite that instruction does the processor just wake up and go, like a PAUSEing spinlock?

I dove into this goop fairly recently so I apologize if these are simple questions.

Hi,

dakami wrote:Poking at some weird things, figured this might be a good place to ask.

Suppose code running on one core, wanted to change RIP (longjmp) on another core.

Is there a direct way to do that? /proc/kallsyms on Linux has a bunch of interesting stuff in low memory, is anything like a memory map of registers? I can imagine poking interrupt vectors but I'm wondering if there's something not quite so passive.

To do these things (on 80x86); you use the local APIC on one CPU to send an "inter-processor interrupt" (IPI) to the other CPU/s. The other CPUs receive the interrupt and start an interrupt hander, where the interrupt handler can do anything you like.

dakami wrote:Alternatively, suppose RIP was sitting on a HLT instruction in main memory. If I just rewrite that instruction does the processor just wake up and go, like a PAUSEing spinlock?

Cross-modifying code requires synchronisation (otherwise the CPU can continue executing the old version of the code without realising it was changed). If one CPU is executing HLT and you replace the HLT instruction, then you'd need an interrupt to break out of the "already executing HLT", where the interrupt handler would serialise the instruction pipeline to make sure the CPU notices that the HLT was replaced with something else.


Cheers,

Brendan

OK this is starting to make a lot more sense.

What's the mechanism for talking to APICs? MMIO or...?

Any idea what latency on MONITOR/MWAIT is? Unlike HLT those *are* waiting for a main memory write.

Hi,

dakami wrote:What's the mechanism for talking to APICs? MMIO or...?

There's the older xAPIC (which is limited to 256 APIC IDs); which is MMIO - each CPU's local APIC is found at the same physical address (a CPU can only talk to its own local APIC). Then there's the newer x2APIC (which can handle a lot more than 256 APIC IDs/CPUs), which uses MSRs instead.

dakami wrote:Any idea what latency on MONITOR/MWAIT is? Unlike HLT those *are* waiting for a main memory write.

All things like this depend on the specific CPU and the specific situation, and for MWAIT itself it also depends on the hints you give it (mostly, which power saving state you tell the CPU to use while waiting). For a generic estimate (for the fastest power saving state only), if the write was done by a CPU within the same core I'd expect latency to be around 10 cycles, and if the write was done by a CPU in a completely different physical package that's multiple "NUMA hops" away I'd expect latency to be more like 100 cycles. For more aggressive power saving states this would increase by however long it takes the CPU to wake up from the power saving state.


Cheers,

Brendan