On Thu, Jan 10, 2019 at 12:57:57PM -0500, Steven Rostedt wrote: > On Thu, 10 Jan 2019 09:42:57 -0800 > Sean Christopherson <sean.j.christopher...@intel.com> wrote: > > > On Thu, Jan 10, 2019 at 12:32:43PM -0500, Steven Rostedt wrote: > > > On Thu, 10 Jan 2019 11:20:04 -0600 > > > Josh Poimboeuf <jpoim...@redhat.com> wrote: > > > > > > > > > > > While I can't find a reason for hypervisors to emulate this > > > > > instruction, > > > > > smarter people might find ways to turn it into a security exploit. > > > > > > > > Interesting point... but I wonder if it's a realistic concern. BTW, > > > > text_poke_bp() also relies on undocumented behavior. > > > > > > But we did get an official OK from Intel that it will work. Took a bit > > > of arm twisting to get them to do so, but they did. And it really is > > > pretty robust. > > > > Did we (they?) list any caveats for this behavior? E.g. I'm fairly > > certain atomicity guarantees go out the window if WC memtype is used. > > Note, the text_poke_bp() process was this: (nothing to do with atomic > guarantees) > > add breakpoint (one byte) to instruction. > > Sync all cores (send an IPI to each one). > > change the back half of the instruction (the rest of the instruction > after the breakpoint). > > Sync all cores > > Remove the breakpoint with the new byte of the new instruction. > > > What atomicity guarantee does the above require?
I was asking in the context of static calls. My understanding is that the write to change the imm32 of the CALL needs to be atomic from a code fetch perspective so that we don't jump to a junk address. Or were you saying that Intel gave an official OK on text_poke_bp()?
