On Mon, Jun 17, 2019 at 10:25:27AM -0700, Andy Lutomirski wrote:
> On Mon, Jun 17, 2019 at 7:42 AM Peter Zijlstra wrote:
> >
> > On Wed, Jun 12, 2019 at 07:44:12PM +, Nadav Amit wrote:
> >
> > > I have run into similar problems before.
> > >
> > > I had two problematic scenarios. In the first
On Mon, Jun 17, 2019 at 7:42 AM Peter Zijlstra wrote:
>
> On Wed, Jun 12, 2019 at 07:44:12PM +, Nadav Amit wrote:
>
> > I have run into similar problems before.
> >
> > I had two problematic scenarios. In the first case, I had a “call” in the
> > middle of the patched code-block, but this
> On Jun 17, 2019, at 7:42 AM, Peter Zijlstra wrote:
>
> On Wed, Jun 12, 2019 at 07:44:12PM +, Nadav Amit wrote:
>
>> I have run into similar problems before.
>>
>> I had two problematic scenarios. In the first case, I had a “call” in the
>> middle of the patched code-block, but this call
On Wed, Jun 12, 2019 at 07:44:12PM +, Nadav Amit wrote:
> I have run into similar problems before.
>
> I had two problematic scenarios. In the first case, I had a “call” in the
> middle of the patched code-block, but this call was always followed by a
> “jump” to the end of the potentially
On Tue, Jun 11, 2019 at 08:54:23AM -0700, Andy Lutomirski wrote:
> > On Jun 11, 2019, at 1:03 AM, Peter Zijlstra wrote:
> > arch_optimize_kprobe() then does the text_poke_bp() that replaces the
> > instruction @addr with int3, copies the rel jump address and overwrites
> > the int3 with jmp.
> >
> On Jun 11, 2019, at 8:55 AM, Peter Zijlstra wrote:
>
> On Tue, Jun 11, 2019 at 11:22:54AM -0400, Steven Rostedt wrote:
>> On Tue, 11 Jun 2019 10:03:07 +0200
>> Peter Zijlstra wrote:
>>
>>
>>> So what happens is that arch_prepare_optimized_kprobe() <-
>>> copy_optimized_instructions() copies
On Fri, Jun 07, 2019 at 07:34:27PM +0200, Peter Zijlstra wrote:
> On Sat, Jun 08, 2019 at 12:47:08AM +0900, Masami Hiramatsu wrote:
> > > @@ -943,8 +949,21 @@ int poke_int3_handler(struct pt_regs *re
> > > if (user_mode(regs) || regs->ip != (unsigned long)bp_int3_addr)
> > > return 0;
On Tue, Jun 11, 2019 at 06:21:28PM +0200, Peter Zijlstra wrote:
> although at this point I'm
> thinking we should just used the instruction decode we have instead of
> playing iffy games with packed structures.
How's something like this? It accepts jmp/32 jmp/8 call and nop5_atomic.
---
Subject:
On Tue, Jun 11, 2019 at 05:52:48PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 11, 2019 at 11:14:10AM -0400, Steven Rostedt wrote:
> > On Wed, 05 Jun 2019 15:08:01 +0200
> > Peter Zijlstra wrote:
> >
> > > -void text_poke_bp(void *addr, const void *opcode, size_t len, void
> > > *handler)
> > >
On Tue, 11 Jun 2019 08:54:23 -0700
Andy Lutomirski wrote:
> How does that help? If RIP == x+2 and you want to put a 5-byte jump
> at address x, no amount of 0xcc is going to change the fact that RIP
> is in the middle of the jump.
>
> Live patching can handle this by detecting this condition
On Tue, Jun 11, 2019 at 11:22:54AM -0400, Steven Rostedt wrote:
> On Tue, 11 Jun 2019 10:03:07 +0200
> Peter Zijlstra wrote:
>
>
> > So what happens is that arch_prepare_optimized_kprobe() <-
> > copy_optimized_instructions() copies however much of the instruction
> > stream is required such
> On Jun 11, 2019, at 1:03 AM, Peter Zijlstra wrote:
>
>> On Fri, Jun 07, 2019 at 11:10:19AM -0700, Andy Lutomirski wrote:
>>
>>
>>> On Jun 7, 2019, at 10:34 AM, Peter Zijlstra wrote:
>>>
>>> On Sat, Jun 08, 2019 at 12:47:08AM +0900, Masami Hiramatsu wrote:
>>>
> This fits almost all
On Tue, Jun 11, 2019 at 11:14:10AM -0400, Steven Rostedt wrote:
> On Wed, 05 Jun 2019 15:08:01 +0200
> Peter Zijlstra wrote:
>
> > -void text_poke_bp(void *addr, const void *opcode, size_t len, void
> > *handler)
> > +void text_poke_bp(void *addr, const void *opcode, size_t len, const void
> >
On Tue, 11 Jun 2019 11:22:54 -0400
Steven Rostedt wrote:
> What would work would be to:
>
> add breakpoint to first opcode.
>
> call synchronize_tasks();
BTW, that should be "synchronize_rcu_tasks()"
-- Steve
>
> /* All tasks now hitting breakpoint and jumping over
On Tue, 11 Jun 2019 10:03:07 +0200
Peter Zijlstra wrote:
> So what happens is that arch_prepare_optimized_kprobe() <-
> copy_optimized_instructions() copies however much of the instruction
> stream is required such that we can overwrite the instruction at @addr
> with a 5 byte jump.
>
>
On Wed, 05 Jun 2019 15:08:01 +0200
Peter Zijlstra wrote:
> -void text_poke_bp(void *addr, const void *opcode, size_t len, void *handler)
> +void text_poke_bp(void *addr, const void *opcode, size_t len, const void
> *emulate)
> {
> unsigned char int3 = 0xcc;
>
> - bp_int3_handler =
On Tue, Jun 11, 2019 at 02:34:02PM +0200, Peter Zijlstra wrote:
> Bugger, this isn't right. It'll jump to the beginning of the trampoline,
> even if it is multiple instructions in, which would lead to executing
> instructions twice, which would be BAD.
>
> _maybe_, depending on what the slot
On Tue, Jun 11, 2019 at 02:08:34PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 11, 2019 at 10:03:07AM +0200, Peter Zijlstra wrote:
> > On Fri, Jun 07, 2019 at 11:10:19AM -0700, Andy Lutomirski wrote:
>
> > > I am surely missing some kprobe context, but is it really safe to use
> > > this mechanism
On Tue, Jun 11, 2019 at 10:03:07AM +0200, Peter Zijlstra wrote:
> On Fri, Jun 07, 2019 at 11:10:19AM -0700, Andy Lutomirski wrote:
> > I am surely missing some kprobe context, but is it really safe to use
> > this mechanism to replace more than one instruction?
>
> I'm not entirely up-to-scratch
On Fri, Jun 07, 2019 at 10:48:06AM -0700, Linus Torvalds wrote:
> On Fri, Jun 7, 2019 at 10:34 AM Peter Zijlstra wrote:
> >
> > I was/am lazy and didn't want to deal with:
> >
> > arch/x86/include/asm/nops.h:#define GENERIC_NOP5_ATOMIC
> > NOP_DS_PREFIX,GENERIC_NOP4
> >
On Fri, Jun 07, 2019 at 11:10:19AM -0700, Andy Lutomirski wrote:
>
>
> > On Jun 7, 2019, at 10:34 AM, Peter Zijlstra wrote:
> >
> > On Sat, Jun 08, 2019 at 12:47:08AM +0900, Masami Hiramatsu wrote:
> >
> >>> This fits almost all text_poke_bp() users, except
> >>> arch_unoptimize_kprobe()
On Wed, Jun 05, 2019 at 03:08:01PM +0200, Peter Zijlstra wrote:
> In preparation for static_call support, teach text_poke_bp() to
> emulate instructions, including CALL.
>
> The current text_poke_bp() takes a @handler argument which is used as
> a jump target when the temporary INT3 is hit by a
On June 7, 2019 11:10:19 AM PDT, Andy Lutomirski wrote:
>
>
>> On Jun 7, 2019, at 10:34 AM, Peter Zijlstra
>wrote:
>>
>> On Sat, Jun 08, 2019 at 12:47:08AM +0900, Masami Hiramatsu wrote:
>>
This fits almost all text_poke_bp() users, except
arch_unoptimize_kprobe() which restores
> On Jun 7, 2019, at 10:34 AM, Peter Zijlstra wrote:
>
> On Sat, Jun 08, 2019 at 12:47:08AM +0900, Masami Hiramatsu wrote:
>
>>> This fits almost all text_poke_bp() users, except
>>> arch_unoptimize_kprobe() which restores random text, and for that site
>>> we have to build an explicit
On Fri, Jun 7, 2019 at 10:34 AM Peter Zijlstra wrote:
>
> I was/am lazy and didn't want to deal with:
>
> arch/x86/include/asm/nops.h:#define GENERIC_NOP5_ATOMIC
> NOP_DS_PREFIX,GENERIC_NOP4
> arch/x86/include/asm/nops.h:#define K8_NOP5_ATOMIC 0x66,K8_NOP4
> arch/x86/include/asm/nops.h:#define
On Sat, Jun 08, 2019 at 12:47:08AM +0900, Masami Hiramatsu wrote:
> > This fits almost all text_poke_bp() users, except
> > arch_unoptimize_kprobe() which restores random text, and for that site
> > we have to build an explicit emulate instruction.
>
> Hm, actually it doesn't restores randome
On Wed, 05 Jun 2019 15:08:01 +0200
Peter Zijlstra wrote:
> In preparation for static_call support, teach text_poke_bp() to
> emulate instructions, including CALL.
>
> The current text_poke_bp() takes a @handler argument which is used as
> a jump target when the temporary INT3 is hit by a
On Fri, 7 Jun 2019 10:20:13 +0200
Peter Zijlstra wrote:
> On Fri, Jun 07, 2019 at 05:41:42AM +, Nadav Amit wrote:
>
> > > int poke_int3_handler(struct pt_regs *regs)
> > > {
> > > + long ip = regs->ip - INT3_INSN_SIZE + CALL_INSN_SIZE;
> > > + struct opcode {
> > > + u8 insn;
> > >
On Fri, Jun 07, 2019 at 05:41:42AM +, Nadav Amit wrote:
> > int poke_int3_handler(struct pt_regs *regs)
> > {
> > + long ip = regs->ip - INT3_INSN_SIZE + CALL_INSN_SIZE;
> > + struct opcode {
> > + u8 insn;
> > + s32 rel;
> > + } __packed opcode;
> > +
> > /*
> >
> On Jun 5, 2019, at 6:08 AM, Peter Zijlstra wrote:
>
> In preparation for static_call support, teach text_poke_bp() to
> emulate instructions, including CALL.
>
> The current text_poke_bp() takes a @handler argument which is used as
> a jump target when the temporary INT3 is hit by a different
In preparation for static_call support, teach text_poke_bp() to
emulate instructions, including CALL.
The current text_poke_bp() takes a @handler argument which is used as
a jump target when the temporary INT3 is hit by a different CPU.
When patching CALL instructions, this doesn't work because
31 matches
Mail list logo
