On Tue, 30 Apr 2019 13:03:59 -0400
Steven Rostedt wrote:
> I also prefer Josh's stack shift solution, as I personally believe
> that's a cleaner solution. But I went ahead and implemented Linus's
> version to get it working for ftrace. Here's the code, and it survived
> some preliminary tests.
W
On Tue, 30 Apr 2019 09:33:51 -0700
Andy Lutomirski wrote:
> Linus, can I ask you to reconsider your opposition to Josh's other
> approach of just shifting the stack on int3 entry? I agree that it's
> ugly, but the ugliness is easily manageable and fairly self-contained.
> We add a little bit of
On Tue, Apr 30, 2019 at 9:06 AM Linus Torvalds
wrote:
>
> On Tue, Apr 30, 2019 at 6:56 AM Peter Zijlstra wrote:
> >
>
> Realistically, I don't think you can hit the problem in practice. The
> only way to hit that incredibly small race of "one instruction, *both*
> NMI and interrupts" is to have a
On Tue, Apr 30, 2019 at 6:56 AM Peter Zijlstra wrote:
>
> On Mon, Apr 29, 2019 at 01:07:33PM -0700, Linus Torvalds wrote:
> >
> > We still have that sti sysexit in the 32-bit code.
>
> We also have both: "STI; HLT" and "STI; MWAIT" where we rely on the STI
> shadow.
I guess the good news is that
On Tue, 30 Apr 2019 16:20:47 +0200
Peter Zijlstra wrote:
> >
> > Sure, but that's a completely different issue. We would need to solve
> > the 'emulate' call for batch mode first.
>
> I don't see a problem there; when INT3 happens; you bsearch() the batch
> array to find the one you hit, you
On Tue, Apr 30, 2019 at 09:44:45AM -0400, Steven Rostedt wrote:
> On Tue, 30 Apr 2019 12:46:48 +0200
> Peter Zijlstra wrote:
>
> > On Mon, Apr 29, 2019 at 02:52:50PM -0400, Steven Rostedt wrote:
> > > On Mon, 29 Apr 2019 11:06:58 -0700
> > > Linus Torvalds wrote:
> > >
> > > > +void replace_c
On Mon, Apr 29, 2019 at 01:07:33PM -0700, Linus Torvalds wrote:
> On Mon, Apr 29, 2019 at 12:24 PM Andy Lutomirski wrote:
> > > Side note: we *already* depend on sti shadow working in other parts of
> > > the kernel, namely sti->iret.
> >
> > Where? STI; IRET would be nuts.
>
> Sorry, not 'sti;
On Tue, 30 Apr 2019 12:46:48 +0200
Peter Zijlstra wrote:
> On Mon, Apr 29, 2019 at 02:52:50PM -0400, Steven Rostedt wrote:
> > On Mon, 29 Apr 2019 11:06:58 -0700
> > Linus Torvalds wrote:
> >
> > > +void replace_call(void *addr, const void *opcode, size_t len, void
> > > *target)
> > > +{
>
On Mon, Apr 29, 2019 at 03:06:30PM -0700, Linus Torvalds wrote:
> On Mon, Apr 29, 2019 at 11:57 AM Andy Lutomirski wrote:
> > >
> > > Otherwise you could never trust the whole sti shadow thing - and it very
> > > much is part of the architecture.
> >
> > Is this documented somewhere?
>
> Btw, if
On Mon, 29 Apr 2019, Linus Torvalds wrote:
> > > It's 486 based, but either way I suspect the answer is "yes". IIRC,
> > > Knights Corner, a.k.a. Larrabee, also had funkiness around SMM and that
> > > was based on P54C, though I'm struggling to recall exactly what the
> > > Larrabee weirdness was
On Mon, Apr 29, 2019 at 02:52:50PM -0400, Steven Rostedt wrote:
> On Mon, 29 Apr 2019 11:06:58 -0700
> Linus Torvalds wrote:
>
> > +void replace_call(void *addr, const void *opcode, size_t len, void *target)
> > +{
> > + bp_int3_call_target = target;
> > + bp_int3_call_return = addr + len;
>
On Mon, Apr 29, 2019 at 07:26:02PM -0700, Linus Torvalds wrote:
> On Mon, Apr 29, 2019 at 5:45 PM Sean Christopherson
> wrote:
> >
> > On Mon, Apr 29, 2019 at 05:08:46PM -0700, Sean Christopherson wrote:
> > >
> > > It's 486 based, but either way I suspect the answer is "yes". IIRC,
> > > Knights
Steven Rostedt writes:
> On Mon, 29 Apr 2019 14:38:35 -0700
> Linus Torvalds wrote:
>
>> On Mon, Apr 29, 2019 at 1:30 PM Steven Rostedt wrote:
>> >
>> > The update from "call custom_trampoline" to "call iterator_trampoline"
>> > is where we have an issue.
>>
>> So it has never worked. Just t
On Mon, Apr 29, 2019 at 5:45 PM Sean Christopherson
wrote:
>
> On Mon, Apr 29, 2019 at 05:08:46PM -0700, Sean Christopherson wrote:
> >
> > It's 486 based, but either way I suspect the answer is "yes". IIRC,
> > Knights Corner, a.k.a. Larrabee, also had funkiness around SMM and that
> > was based
On Mon, Apr 29, 2019 at 05:08:46PM -0700, Sean Christopherson wrote:
> On Mon, Apr 29, 2019 at 03:22:09PM -0700, Linus Torvalds wrote:
> > On Mon, Apr 29, 2019 at 3:08 PM Sean Christopherson
> > wrote:
> > >
> > > FWIW, Lakemont (Quark) doesn't block NMI/SMI in the STI shadow, but I'm
> > > not su
On Mon, Apr 29, 2019 at 03:22:09PM -0700, Linus Torvalds wrote:
> On Mon, Apr 29, 2019 at 3:08 PM Sean Christopherson
> wrote:
> >
> > FWIW, Lakemont (Quark) doesn't block NMI/SMI in the STI shadow, but I'm
> > not sure that counters the "horrible errata" statement ;-). SMI+RSM saves
> > and rest
On Mon, Apr 29, 2019 at 3:08 PM Sean Christopherson
wrote:
>
> FWIW, Lakemont (Quark) doesn't block NMI/SMI in the STI shadow, but I'm
> not sure that counters the "horrible errata" statement ;-). SMI+RSM saves
> and restores STI blocking in that case, but AFAICT NMI has no such
> protection and
On Mon, Apr 29, 2019 at 11:57 AM Andy Lutomirski wrote:
> >
> > Otherwise you could never trust the whole sti shadow thing - and it very
> > much is part of the architecture.
>
> Is this documented somewhere?
Btw, if you really don't trust the sti shadow despite it going all the
way back to the
On Mon, Apr 29, 2019 at 01:16:10PM -0700, Linus Torvalds wrote:
> On Mon, Apr 29, 2019 at 12:02 PM Linus Torvalds
> wrote:
> >
> > If nmi were to break it, it would be a cpu bug. I'm pretty sure I've
> > seen the "shadow stops even nmi" documented for some uarch, but as
> > mentioned it's not nece
On Mon, 29 Apr 2019 14:38:35 -0700
Linus Torvalds wrote:
> On Mon, Apr 29, 2019 at 1:30 PM Steven Rostedt wrote:
> >
> > The update from "call custom_trampoline" to "call iterator_trampoline"
> > is where we have an issue.
>
> So it has never worked. Just tell people that they have two chocie
On Mon, Apr 29, 2019 at 1:30 PM Steven Rostedt wrote:
>
> The update from "call custom_trampoline" to "call iterator_trampoline"
> is where we have an issue.
So it has never worked. Just tell people that they have two chocies:
- you do the careful rewriting, which takes more time
- you do it
On Mon, 29 Apr 2019 13:06:17 -0700
Linus Torvalds wrote:
> On Mon, Apr 29, 2019 at 12:07 PM Steven Rostedt wrote:
> >
> > Are you suggesting that I rewrite the code to do it one function at a
> > time? This has always been batch mode. This is not something new. The
> > function tracer has been a
On Mon, Apr 29, 2019 at 1:06 PM Linus Torvalds
wrote:
>
> Only do the 'call' instructions one at a time. Why would you change
> _existing_ code?
Side note: if you want to, you can easily batch up rewriting 'call'
instructions to the same target using the exact same code. You just
need to change t
On Mon, Apr 29, 2019 at 12:02 PM Linus Torvalds
wrote:
>
> If nmi were to break it, it would be a cpu bug. I'm pretty sure I've
> seen the "shadow stops even nmi" documented for some uarch, but as
> mentioned it's not necessarily the only way to guarantee the shadow.
In fact, the documentation is
On Mon, Apr 29, 2019 at 12:07 PM Steven Rostedt wrote:
>
> Are you suggesting that I rewrite the code to do it one function at a
> time? This has always been batch mode. This is not something new. The
> function tracer has been around longer than the text poke code.
Only do the 'call' instruction
On Mon, Apr 29, 2019 at 12:24 PM Andy Lutomirski wrote:
> > Side note: we *already* depend on sti shadow working in other parts of the
> > kernel, namely sti->iret.
>
> Where? STI; IRET would be nuts.
Sorry, not 'sti;iret' but 'sti;sysexit'
> before commit 4214a16b02971c60960afd675d03544e109e0
On Mon, Apr 29, 2019 at 12:13 PM Linus Torvalds
wrote:
>
>
>
> On Mon, Apr 29, 2019, 12:02 Linus Torvalds
> wrote:
>>
>>
>>
>> If nmi were to break it, it would be a cpu bug.
>
>
> Side note: we *already* depend on sti shadow working in other parts of the
> kernel, namely sti->iret.
>
Where?
On Mon, 29 Apr 2019 11:59:04 -0700
Linus Torvalds wrote:
> I really don't care. Just do what I suggested, and if you have numbers to
> show problems, then maybe I'll care.
>
Are you suggesting that I rewrite the code to do it one function at a
time? This has always been batch mode. This is not
On Mon, Apr 29, 2019 at 11:53 AM Linus Torvalds
wrote:
>
>
>
> On Mon, Apr 29, 2019, 11:42 Andy Lutomirski wrote:
>>
>>
>> I'm less than 100% convinced about this argument. Sure, an NMI right
>> there won't cause a problem. But an NMI followed by an interrupt will
>> kill us if preemption is on
On Mon, 29 Apr 2019 11:06:58 -0700
Linus Torvalds wrote:
> +void replace_call(void *addr, const void *opcode, size_t len, void *target)
> +{
> + bp_int3_call_target = target;
> + bp_int3_call_return = addr + len;
> + bp_int3_handler_irqoff = emulate_call_irqoff;
> + text_poke_bp(a
On Mon, Apr 29, 2019 at 11:29 AM Linus Torvalds
wrote:
>
> On Mon, Apr 29, 2019 at 11:06 AM Linus Torvalds
> wrote:
> >
> >
> > It does *not* emulate the "call" in the BP handler itself, instead if
> > replace the %ip (the same way all the other BP handlers replace the
> > %ip) with a code sequen
On Mon, Apr 29, 2019 at 11:06 AM Linus Torvalds
wrote:
>
>
> It does *not* emulate the "call" in the BP handler itself, instead if
> replace the %ip (the same way all the other BP handlers replace the
> %ip) with a code sequence that just does
>
> push %gs:bp_call_return
> jmp *%gs
On Sun, Apr 28, 2019 at 10:38 AM Steven Rostedt wrote:
>
> For optimization reasons, if there's only a single user of a function
> it gets its own trampoline that sets up the call to its callback and
> calls that callback directly:
So this is the same issue as the static calls, and it has exactly
[ Added Linus ]
On Sat, 27 Apr 2019 12:26:57 +0200
Peter Zijlstra wrote:
> On Sat, Apr 27, 2019 at 12:06:38PM +0200, Nicolai Stange wrote:
> > ftrace_int3_handler()'s context is different from the interrupted call
> > instruction's one, obviously. In order to be able to emulate the call
> > wi
On Sat, Apr 27, 2019 at 12:06:38PM +0200, Nicolai Stange wrote:
> ftrace_int3_handler()'s context is different from the interrupted call
> instruction's one, obviously. In order to be able to emulate the call
> within the original context, make ftrace_int3_handler() set its iret
> frame's ->ip to s
With dynamic ftrace, ftrace patches call sites on x86 in a three steps:
1. Put a breakpoint at the to be patched location,
2. update call site and
3. finally remove the breakpoint again.
Note that the breakpoint ftrace_int3_handler() simply makes execution to
skip over the to be patched instructio
36 matches
Mail list logo
