On Thu, Nov 29, 2018 at 03:04:20PM -0800, Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 12:25 PM Josh Poimboeuf wrote:
> >
> > On Thu, Nov 29, 2018 at 11:27:00AM -0800, Andy Lutomirski wrote:
> > >
> > > I propose a different solution:
> > >
> > > As in this patch set, we have a direct and an in
On Tue, Dec 11, 2018 at 09:41:37AM +, David Laight wrote:
> From: Josh Poimboeuf
> > Sent: 30 November 2018 16:27
> >
> > On Thu, Nov 29, 2018 at 03:04:20PM -0800, Linus Torvalds wrote:
> > > On Thu, Nov 29, 2018 at 12:25 PM Josh Poimboeuf
> > > wrote:
> ...
> > > > Maybe that would be ok.
From: Josh Poimboeuf
> Sent: 30 November 2018 16:27
>
> On Thu, Nov 29, 2018 at 03:04:20PM -0800, Linus Torvalds wrote:
> > On Thu, Nov 29, 2018 at 12:25 PM Josh Poimboeuf wrote:
...
> > > Maybe that would be ok. If my math is right, we would use the
> > > out-of-line version almost 5% of the ti
On Mon, Dec 10, 2018 at 3:58 PM Pavel Machek wrote:
>
> On Thu 2018-11-29 11:11:50, Linus Torvalds wrote:
> >
> > It might be better to use an empty REX prefix on x86-64 or something like
> > that.
>
> It might be easiest to use plain old NOP, no? :-).
No. The whole point would be that the instr
On Thu 2018-11-29 11:11:50, Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 11:08 AM Linus Torvalds
> wrote:
> >
> > What you can do then is basically add a single-byte prefix to the
> > "call" instruction that does nothing (say, cs override), and then
> > replace *that* with a 'int3' instruction.
On Fri, Nov 30, 2018 at 11:16:34PM +0100, Rasmus Villemoes wrote:
> On 29/11/2018 20.22, Josh Poimboeuf wrote:
> > On Thu, Nov 29, 2018 at 02:16:48PM -0500, Steven Rostedt wrote:
> >>> and honestly, the way "static_call()" works now, can you guarantee
> >>> that the call-site doesn't end up doing t
On 29/11/2018 20.22, Josh Poimboeuf wrote:
> On Thu, Nov 29, 2018 at 02:16:48PM -0500, Steven Rostedt wrote:
>>> and honestly, the way "static_call()" works now, can you guarantee
>>> that the call-site doesn't end up doing that, and calling the
>>> trampoline function for two different static call
On Fri, 30 Nov 2018, Andy Lutomirski wrote:
> According to the SDM, you can program the APIC ICR to request an SMI.
> It's not remotely clear to me what will happen if we do this.
I think one of the known reliable ways to trigger SMI is to write 0x0 to
the SMI command I/O port (0xb2).
> For
On Fri, Nov 30, 2018 at 12:18:33PM -0800, Andy Lutomirski wrote:
> On Fri, Nov 30, 2018 at 11:51 AM Linus Torvalds
> wrote:
> >
> > On Fri, Nov 30, 2018 at 10:39 AM Josh Poimboeuf wrote:
> > >
> > > AFAICT, all the other proposed options seem to have major issues.
> >
> > I still absolutely detes
On Fri, 30 Nov 2018 12:59:36 -0800
Andy Lutomirski wrote:
> For all I know, the SMI handler will explode and the computer will catch fire.
That sounds like an AWESOME feature!!!
-- Steve
On Fri, Nov 30, 2018 at 12:28 PM Steven Rostedt wrote:
>
> On Fri, 30 Nov 2018 12:18:33 -0800
> Andy Lutomirski wrote:
>
> > Or we could replace that IPI with x86's bona fide serialize-all-cpus
> > primitive and then we can just retry instead of emulating. It's a
> > piece of cake -- we just tri
On Fri, 30 Nov 2018 12:18:33 -0800
Andy Lutomirski wrote:
> Or we could replace that IPI with x86's bona fide serialize-all-cpus
> primitive and then we can just retry instead of emulating. It's a
> piece of cake -- we just trigger an SMI :) /me runs away.
I must have fallen on my head one too
On Fri, Nov 30, 2018 at 11:51 AM Linus Torvalds
wrote:
>
> On Fri, Nov 30, 2018 at 10:39 AM Josh Poimboeuf wrote:
> >
> > AFAICT, all the other proposed options seem to have major issues.
>
> I still absolutely detest this patch, and in fact it got worse from
> the test of the config variable.
>
On Fri, Nov 30, 2018 at 10:39 AM Josh Poimboeuf wrote:
>
> AFAICT, all the other proposed options seem to have major issues.
I still absolutely detest this patch, and in fact it got worse from
the test of the config variable.
Honestly, the entry code being legible and simple is more important
th
On Fri, Nov 30, 2018 at 08:42:26AM -0800, Andy Lutomirski wrote:
> On Thu, Nov 29, 2018 at 12:24 PM Josh Poimboeuf wrote:
> >
> > > Alternatively, we could actually emulate call instructions like this:
> > >
> > > void __noreturn jump_to_kernel_pt_regs(struct pt_regs *regs, ...)
> > > {
> > > st
On Thu, Nov 29, 2018 at 12:24 PM Josh Poimboeuf wrote:
>
> > Alternatively, we could actually emulate call instructions like this:
> >
> > void __noreturn jump_to_kernel_pt_regs(struct pt_regs *regs, ...)
> > {
> > struct pt_regs ptregs_copy = *regs;
> > barrier();
> > *(unsigned long *)(reg
On Thu, Nov 29, 2018 at 03:04:20PM -0800, Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 12:25 PM Josh Poimboeuf wrote:
> >
> > On Thu, Nov 29, 2018 at 11:27:00AM -0800, Andy Lutomirski wrote:
> > >
> > > I propose a different solution:
> > >
> > > As in this patch set, we have a direct and an in
On Thu, Nov 29, 2018 at 12:25 PM Josh Poimboeuf wrote:
>
> On Thu, Nov 29, 2018 at 11:27:00AM -0800, Andy Lutomirski wrote:
> >
> > I propose a different solution:
> >
> > As in this patch set, we have a direct and an indirect version. The
> > indirect version remains exactly the same as in this
On Thu, Nov 29, 2018 at 04:14:46PM -0600, Josh Poimboeuf wrote:
> On Thu, Nov 29, 2018 at 11:01:48PM +0100, Peter Zijlstra wrote:
> > On Thu, Nov 29, 2018 at 11:10:50AM -0600, Josh Poimboeuf wrote:
> > > On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
> >
> > > > (like pointing IP
On Thu, Nov 29, 2018 at 02:25:33PM -0800, Andy Lutomirski wrote:
> On Thu, Nov 29, 2018 at 2:22 PM Peter Zijlstra wrote:
> >
> > On Thu, Nov 29, 2018 at 04:14:46PM -0600, Josh Poimboeuf wrote:
> > > On Thu, Nov 29, 2018 at 11:01:48PM +0100, Peter Zijlstra wrote:
> > > > On Thu, Nov 29, 2018 at 11:
On Thu, Nov 29, 2018 at 2:22 PM Peter Zijlstra wrote:
>
> On Thu, Nov 29, 2018 at 04:14:46PM -0600, Josh Poimboeuf wrote:
> > On Thu, Nov 29, 2018 at 11:01:48PM +0100, Peter Zijlstra wrote:
> > > On Thu, Nov 29, 2018 at 11:10:50AM -0600, Josh Poimboeuf wrote:
> > > > On Thu, Nov 29, 2018 at 08:59:
On Thu, Nov 29, 2018 at 02:24:52PM -0600, Josh Poimboeuf wrote:
> On Thu, Nov 29, 2018 at 11:27:00AM -0800, Andy Lutomirski wrote:
> > On Thu, Nov 29, 2018 at 11:08 AM Linus Torvalds
> > wrote:
> > >
> > > On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds
> > > wrote:
> > > >
> > > > In contrast, i
On Thu, Nov 29, 2018 at 11:01:48PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 29, 2018 at 11:10:50AM -0600, Josh Poimboeuf wrote:
> > On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
>
> > > (like pointing IP at a stub that retpolines to the target by reading
> > > the function poi
On Thu, Nov 29, 2018 at 11:10:50AM -0600, Josh Poimboeuf wrote:
> On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
> > (like pointing IP at a stub that retpolines to the target by reading
> > the function pointer, a la the unoptimizable version), then okay, I
> > guess, with only a
On Thu, Nov 29, 2018 at 11:27:00AM -0800, Andy Lutomirski wrote:
> On Thu, Nov 29, 2018 at 11:08 AM Linus Torvalds
> wrote:
> >
> > On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds
> > wrote:
> > >
> > > In contrast, if the call was wrapped in an inline asm, we'd *know* the
> > > compiler couldn't
On Thu, Nov 29, 2018 at 10:58:40AM -0800, Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 10:47 AM Steven Rostedt wrote:
> >
> > Note, we do have a bit of control at what is getting called. The patch
> > set requires that the callers are wrapped in macros. We should not
> > allow just any random c
On Thu, 29 Nov 2018 11:24:43 -0800
Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 11:16 AM Steven Rostedt wrote:
> >
> > But then we need to implement all numbers of parameters.
>
> Oh, I agree, it's nasty.
>
> But it's actually a nastiness that we've solved before. In particular,
> with th
On Thu, Nov 29, 2018 at 11:25 AM Linus Torvalds
wrote:
>
> On Thu, Nov 29, 2018 at 11:16 AM Steven Rostedt wrote:
> >
> > But then we need to implement all numbers of parameters.
>
> Oh, I agree, it's nasty.
>
> But it's actually a nastiness that we've solved before. In particular,
> with the sys
On Thu, 29 Nov 2018 13:22:11 -0600
Josh Poimboeuf wrote:
> On Thu, Nov 29, 2018 at 02:16:48PM -0500, Steven Rostedt wrote:
> > > and honestly, the way "static_call()" works now, can you guarantee
> > > that the call-site doesn't end up doing that, and calling the
> > > trampoline function for two
On Thu, Nov 29, 2018 at 11:08 AM Linus Torvalds
wrote:
>
> On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds
> wrote:
> >
> > In contrast, if the call was wrapped in an inline asm, we'd *know* the
> > compiler couldn't turn a "call wrapper(%rip)" into anything else.
>
> Actually, I think I have a b
On Thu, Nov 29, 2018 at 11:16 AM Steven Rostedt wrote:
>
> But then we need to implement all numbers of parameters.
Oh, I agree, it's nasty.
But it's actually a nastiness that we've solved before. In particular,
with the system call mappings, which have pretty much the exact same
issue of "map u
On Thu, Nov 29, 2018 at 02:16:48PM -0500, Steven Rostedt wrote:
> > and honestly, the way "static_call()" works now, can you guarantee
> > that the call-site doesn't end up doing that, and calling the
> > trampoline function for two different static calls from one indirect
> > call?
> >
> > See wh
On Thu, 29 Nov 2018 10:58:40 -0800
Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 10:47 AM Steven Rostedt wrote:
> >
> > Note, we do have a bit of control at what is getting called. The patch
> > set requires that the callers are wrapped in macros. We should not
> > allow just any random caller
On Thu, 29 Nov 2018 11:08:26 -0800
Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds
> wrote:
> >
> > In contrast, if the call was wrapped in an inline asm, we'd *know* the
> > compiler couldn't turn a "call wrapper(%rip)" into anything else.
>
> Actually, I think I have
On Thu, Nov 29, 2018 at 11:08 AM Linus Torvalds
wrote:
>
> What you can do then is basically add a single-byte prefix to the
> "call" instruction that does nothing (say, cs override), and then
> replace *that* with a 'int3' instruction.
Hmm. the segment prefixes are documented as being "reserved"
On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds
wrote:
>
> In contrast, if the call was wrapped in an inline asm, we'd *know* the
> compiler couldn't turn a "call wrapper(%rip)" into anything else.
Actually, I think I have a better model - if the caller is done with inline asm.
What you can do t
On Thu, Nov 29, 2018 at 10:47 AM Steven Rostedt wrote:
>
> Note, we do have a bit of control at what is getting called. The patch
> set requires that the callers are wrapped in macros. We should not
> allow just any random callers (like from asm).
Actually, I'd argue that asm is often more contro
On Thu, 29 Nov 2018 10:00:48 -0800
Andy Lutomirski wrote:
> >
> > Of course, another option is to just say "we don't do the inline case,
> > then", and only ever do a call to a stub that does a "jmp"
> > instruction.
>
> That’s not a terrible idea.
It was the implementation of my first proof
On Thu, 29 Nov 2018 10:23:44 -0800
Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 9:59 AM Steven Rostedt wrote:
> >
> > Do you realize that the cmpxchg used by the first attempts of the
> > dynamic modification of code by ftrace was the source of the e1000e
> > NVRAM corruption bug.
>
> If y
On Thu, Nov 29, 2018 at 10:00 AM Andy Lutomirski wrote:
> > then it really sounds pretty safe to just say "ok, just make it
> > aligned and update the instruction with an atomic cmpxchg or
> > something".
>
> And how do we do that? With a gcc plugin and some asm magic?
Asm magic.
You already ha
On Thu, Nov 29, 2018 at 06:15:39PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
>
> > If you make it conditional on CPL, do it for 32-bit as well, add
> > comments,
>
> > and convince yourself that there isn’t a better solution
> > (like pointin
On Thu, Nov 29, 2018 at 9:59 AM Steven Rostedt wrote:
>
> Do you realize that the cmpxchg used by the first attempts of the
> dynamic modification of code by ftrace was the source of the e1000e
> NVRAM corruption bug.
If you have a static call in IO memory, you have bigger problems than that.
Wh
> On Nov 29, 2018, at 9:50 AM, Linus Torvalds
> wrote:
>
>> On Thu, Nov 29, 2018 at 9:44 AM Steven Rostedt wrote:
>>
>> Well, the current method (as Jiri mentioned) did get the OK from at
>> least Intel (and that was with a lot of arm twisting to do so).
>
> Guys, when the comparison is to:
On Thu, 29 Nov 2018 09:50:28 -0800
Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 9:44 AM Steven Rostedt wrote:
> >
> > Well, the current method (as Jiri mentioned) did get the OK from at
> > least Intel (and that was with a lot of arm twisting to do so).
>
> Guys, when the comparison is to:
On Thu, Nov 29, 2018 at 9:50 AM Linus Torvalds
wrote:
>
> - corrupt random registers because we "know" they aren't in use
Just to clarify: I think that's a completely unacceptable model.
We already have lots of special calling conventions, including ones
that do not have any call-clobbered regi
> On Nov 29, 2018, at 9:45 AM, Josh Poimboeuf wrote:
>
>> On Thu, Nov 29, 2018 at 09:41:33AM -0800, Andy Lutomirski wrote:
>>
>>> On Nov 29, 2018, at 9:21 AM, Steven Rostedt wrote:
>>>
>>> On Thu, 29 Nov 2018 12:20:00 -0500
>>> Steven Rostedt wrote:
>>>
>>>
r8 = return address
r
On Thu, Nov 29, 2018 at 9:44 AM Steven Rostedt wrote:
>
> Well, the current method (as Jiri mentioned) did get the OK from at
> least Intel (and that was with a lot of arm twisting to do so).
Guys, when the comparison is to:
- create a huge honking security hole by screwing up the stack frame
On Thu, 29 Nov 2018 09:41:33 -0800
Andy Lutomirski wrote:
> > On Nov 29, 2018, at 9:21 AM, Steven Rostedt wrote:
> >
> > On Thu, 29 Nov 2018 12:20:00 -0500
> > Steven Rostedt wrote:
> >
> >
> >> r8 = return address
> >> r9 = function to call
> >>
> >
> > Bad example, r8 and r9 are args
On Thu, Nov 29, 2018 at 09:41:33AM -0800, Andy Lutomirski wrote:
>
> > On Nov 29, 2018, at 9:21 AM, Steven Rostedt wrote:
> >
> > On Thu, 29 Nov 2018 12:20:00 -0500
> > Steven Rostedt wrote:
> >
> >
> >> r8 = return address
> >> r9 = function to call
> >>
> >
> > Bad example, r8 and r9 are
On Thu, 29 Nov 2018 09:35:11 -0800
Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 9:13 AM Steven Rostedt wrote:
> >
> > No, we really do need to sync after we change the second part of the
> > command with the int3 on it. Unless there's another way to guarantee
> > that the full instruction get
> On Nov 29, 2018, at 9:21 AM, Steven Rostedt wrote:
>
> On Thu, 29 Nov 2018 12:20:00 -0500
> Steven Rostedt wrote:
>
>
>> r8 = return address
>> r9 = function to call
>>
>
> Bad example, r8 and r9 are args, but r10 and r11 are available.
>
> -- Steve
>
>>push r8
>>jmp *r9
>>
>>
On Thu, Nov 29, 2018 at 9:13 AM Steven Rostedt wrote:
>
> No, we really do need to sync after we change the second part of the
> command with the int3 on it. Unless there's another way to guarantee
> that the full instruction gets seen when we replace the int3 with the
> finished command.
Making
> On Nov 29, 2018, at 9:29 AM, Linus Torvalds
> wrote:
>
> On Thu, Nov 29, 2018 at 9:02 AM Andy Lutomirski wrote:
>>>
>>> - just restart the instruction (with the suggested "ptregs->rip --")
>>>
>>> - to avoid any "oh, we're not making progress" issues, just fix the
>>> instruction yoursel
On Thu, 29 Nov 2018, Andy Lutomirski wrote:
> Does anyone know what the actual hardware semantics are? The SDM is not
> particularly informative unless I looked at the wrong section.
I don't think SDM answers all the questions there, unfortunately.
I vaguely remember that back then when I was
On Thu, Nov 29, 2018 at 9:02 AM Andy Lutomirski wrote:
> >
> > - just restart the instruction (with the suggested "ptregs->rip --")
> >
> > - to avoid any "oh, we're not making progress" issues, just fix the
> > instruction yourself to be the right call, by looking it up in the
> > "what needs to
> On Nov 29, 2018, at 9:07 AM, Peter Zijlstra wrote:
>
> On Thu, Nov 29, 2018 at 09:02:23AM -0800, Andy Lutomirski wrote:
>>> On Nov 29, 2018, at 8:50 AM, Linus Torvalds
>>> wrote:
>
>>> So no. Do *not* try to change %rsp on the stack in the bp handler.
>>> Instead, I'd suggest:
>>>
>>> -
On Thu, 29 Nov 2018 12:20:00 -0500
Steven Rostedt wrote:
> r8 = return address
> r9 = function to call
>
Bad example, r8 and r9 are args, but r10 and r11 are available.
-- Steve
> push r8
> jmp *r9
>
> Then have the regs->ip point to that trampoline.
>
> -- Steve
On Thu, 29 Nov 2018 18:15:39 +0100
Peter Zijlstra wrote:
> On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
>
> > If you make it conditional on CPL, do it for 32-bit as well, add
> > comments,
>
> > and convince yourself that there isn’t a better solution
> > (like pointing I
On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
> If you make it conditional on CPL, do it for 32-bit as well, add
> comments,
> and convince yourself that there isn’t a better solution
> (like pointing IP at a stub that retpolines to the target by reading
> the function pointer
On Thu, 29 Nov 2018 09:02:23 -0800
Andy Lutomirski wrote:
> > Instead, I'd suggest:
> >
> > - just restart the instruction (with the suggested "ptregs->rip --")
> >
> > - to avoid any "oh, we're not making progress" issues, just fix the
> > instruction yourself to be the right call, by looking
On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
>
>
> > On Nov 29, 2018, at 8:49 AM, Peter Zijlstra wrote:
> >
> > On Thu, Nov 29, 2018 at 10:33:42AM -0600, Josh Poimboeuf wrote:
> >>> can't we 'fix' that again? The alternative is moving that IRET-frame and
> >>> fixing everyth
On Thu, Nov 29, 2018 at 09:02:23AM -0800, Andy Lutomirski wrote:
> > On Nov 29, 2018, at 8:50 AM, Linus Torvalds
> > wrote:
> > So no. Do *not* try to change %rsp on the stack in the bp handler.
> > Instead, I'd suggest:
> >
> > - just restart the instruction (with the suggested "ptregs->rip --
> On Nov 29, 2018, at 8:50 AM, Linus Torvalds
> wrote:
>
>> On Thu, Nov 29, 2018 at 8:33 AM Josh Poimboeuf wrote:
>>
>> This seems to work...
>>
>> + .if \create_gap == 1
>> + .rept 6
>> + pushq 5*8(%rsp)
>> + .endr
>> + .endif
>> +
>> -idtentry int3
> On Nov 29, 2018, at 8:49 AM, Peter Zijlstra wrote:
>
> On Thu, Nov 29, 2018 at 10:33:42AM -0600, Josh Poimboeuf wrote:
>>> can't we 'fix' that again? The alternative is moving that IRET-frame and
>>> fixing everything up, which is going to be fragile, ugly and such
>>> things more.
>
>> Thi
On Thu, 29 Nov 2018 08:50:16 -0800
Linus Torvalds wrote:
> Instead, I'd suggest:
>
> - just restart the instruction (with the suggested "ptregs->rip --")
>
> - to avoid any "oh, we're not making progress" issues, just fix the
> instruction yourself to be the right call, by looking it up in th
On Thu, Nov 29, 2018 at 8:33 AM Josh Poimboeuf wrote:
>
> This seems to work...
>
> + .if \create_gap == 1
> + .rept 6
> + pushq 5*8(%rsp)
> + .endr
> + .endif
> +
> -idtentry int3 do_int3 has_error_code=0
> +idtentry int3
On Thu, Nov 29, 2018 at 10:33:42AM -0600, Josh Poimboeuf wrote:
> > can't we 'fix' that again? The alternative is moving that IRET-frame and
> > fixing everything up, which is going to be fragile, ugly and such
> > things more.
> This seems to work...
That's almost too easy... nice!
> diff --git
On Thu, Nov 29, 2018 at 03:38:53PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 29, 2018 at 05:37:39AM -0800, Andy Lutomirski wrote:
> >
> >
> > > On Nov 29, 2018, at 1:42 AM, Peter Zijlstra wrote:
> > >
> > > On Wed, Nov 28, 2018 at 10:05:54PM -0800, Andy Lutomirski wrote:
> > >
> > +stati
On Thu, 29 Nov 2018, Peter Zijlstra wrote:
> > int3 isn’t IST anymore, so the int3 instruction conditionally
> > subtracts 8 from RSP and then pushes SS, etc. So my email was
> > obviously wrong wrt “cs”, but you’re still potentially overwriting the
> > int3 IRET frame.
>
> ARGH!..
>
> can't
On Thu, Nov 29, 2018 at 05:37:39AM -0800, Andy Lutomirski wrote:
>
>
> > On Nov 29, 2018, at 1:42 AM, Peter Zijlstra wrote:
> >
> > On Wed, Nov 28, 2018 at 10:05:54PM -0800, Andy Lutomirski wrote:
> >
> +static void static_call_bp_handler(struct pt_regs *regs, void *_data)
> +{
> >>>
> On Nov 29, 2018, at 1:42 AM, Peter Zijlstra wrote:
>
> On Wed, Nov 28, 2018 at 10:05:54PM -0800, Andy Lutomirski wrote:
>
+static void static_call_bp_handler(struct pt_regs *regs, void *_data)
+{
+struct static_call_bp_data *data = _data;
+
+/*
+ *
On Thu, Nov 29, 2018 at 10:42:10AM +0100, Peter Zijlstra wrote:
> On Wed, Nov 28, 2018 at 10:05:54PM -0800, Andy Lutomirski wrote:
>
> > >> +static void static_call_bp_handler(struct pt_regs *regs, void *_data)
> > >> +{
> > >> +struct static_call_bp_data *data = _data;
> > >> +
> > >> +/*
On Wed, Nov 28, 2018 at 10:05:54PM -0800, Andy Lutomirski wrote:
> >> +static void static_call_bp_handler(struct pt_regs *regs, void *_data)
> >> +{
> >> +struct static_call_bp_data *data = _data;
> >> +
> >> +/*
> >> + * For inline static calls, push the return address on the stack so
> On Nov 27, 2018, at 12:43 AM, Peter Zijlstra wrote:
>
>> On Mon, Nov 26, 2018 at 03:26:28PM -0600, Josh Poimboeuf wrote:
>>
>> Yeah, that's probably better. I assume you also mean that we would have
>> all text_poke_bp() users create a handler callback? That way the
>> interface is clear and c
On Tue, Nov 27, 2018 at 09:43:30AM +0100, Peter Zijlstra wrote:
> Now; if I'm not mistaken, the below @site is in fact @regs->ip - 1, no?
>
> We already patched site with INT3, which is what we just trapped on. So
> we could in fact write something like:
>
> static void static_call_bp_handler(str
On Mon, Nov 26, 2018 at 02:14:49PM -0600, Josh Poimboeuf wrote:
> On Mon, Nov 26, 2018 at 10:28:08AM -0800, Andy Lutomirski wrote:
> > Can you add a comment that it will need updating when kernel CET is added?
>
> Will do, though I get the feeling there's a lot of other (existing) code
> that wil
On Mon, Nov 26, 2018 at 03:26:28PM -0600, Josh Poimboeuf wrote:
> Yeah, that's probably better. I assume you also mean that we would have
> all text_poke_bp() users create a handler callback? That way the
> interface is clear and consistent for everybody. Like:
Can do, it does indeed make the
On Mon, Nov 26, 2018 at 09:08:01PM +0100, Peter Zijlstra wrote:
> On Mon, Nov 26, 2018 at 11:56:24AM -0600, Josh Poimboeuf wrote:
> > diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
> > index d3869295b88d..8fd6c8556750 100644
> > --- a/arch/x86/kernel/static_call.c
> > ++
On Mon, Nov 26, 2018 at 10:28:08AM -0800, Andy Lutomirski wrote:
> On Mon, Nov 26, 2018 at 9:10 AM Josh Poimboeuf wrote:
> >
> > On Mon, Nov 26, 2018 at 05:02:17PM +0100, Peter Zijlstra wrote:
> > > On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote:
> > > > diff --git a/arch/x86/kerne
On Mon, Nov 26, 2018 at 11:56:24AM -0600, Josh Poimboeuf wrote:
> diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
> index d3869295b88d..8fd6c8556750 100644
> --- a/arch/x86/kernel/static_call.c
> +++ b/arch/x86/kernel/static_call.c
> @@ -7,24 +7,19 @@
>
> #define CALL_
On Mon, Nov 26, 2018 at 11:56:24AM -0600, Josh Poimboeuf wrote:
> Peter suggested updating the text_poke_bp() interface to add a handler
> which is called from int3 context. This seems to work.
> @@ -760,8 +761,10 @@ int poke_int3_handler(struct pt_regs *regs)
> if (user_mode(regs) || regs-
On Mon, Nov 26, 2018 at 9:10 AM Josh Poimboeuf wrote:
>
> On Mon, Nov 26, 2018 at 05:02:17PM +0100, Peter Zijlstra wrote:
> > On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote:
> > > diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
> > > index 8026d176f25c..d
On Mon, Nov 26, 2018 at 11:10:36AM -0600, Josh Poimboeuf wrote:
> On Mon, Nov 26, 2018 at 05:02:17PM +0100, Peter Zijlstra wrote:
> > On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote:
> > > diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
> > > index 8026d176
On Mon, Nov 26, 2018 at 05:02:17PM +0100, Peter Zijlstra wrote:
> On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote:
> > diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
> > index 8026d176f25c..d3869295b88d 100644
> > --- a/arch/x86/kernel/static_call.c
> > ++
On Mon, Nov 26, 2018 at 05:39:23PM +0100, Peter Zijlstra wrote:
> On Mon, Nov 26, 2018 at 05:11:05PM +0100, Ard Biesheuvel wrote:
> > On Mon, 26 Nov 2018 at 17:08, Peter Zijlstra wrote:
> > >
> > > On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote:
> > > > +#ifdef CONFIG_HAVE_STATIC_C
On Mon, Nov 26, 2018 at 05:11:05PM +0100, Ard Biesheuvel wrote:
> On Mon, 26 Nov 2018 at 17:08, Peter Zijlstra wrote:
> >
> > On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote:
> > > +#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
> > > +void arch_static_call_defuse_tramp(void *site, void *tra
On Mon, Nov 26, 2018 at 8:11 AM Ard Biesheuvel
wrote:
>
> On Mon, 26 Nov 2018 at 17:08, Peter Zijlstra wrote:
> >
> > On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote:
> > > +#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
> > > +void arch_static_call_defuse_tramp(void *site, void *tramp)
> >
On Mon, 26 Nov 2018 at 17:08, Peter Zijlstra wrote:
>
> On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote:
> > +#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
> > +void arch_static_call_defuse_tramp(void *site, void *tramp)
> > +{
> > + unsigned short opcode = INSN_UD2;
> > +
> > + mut
On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote:
> +#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
> +void arch_static_call_defuse_tramp(void *site, void *tramp)
> +{
> + unsigned short opcode = INSN_UD2;
> +
> + mutex_lock(&text_mutex);
> + text_poke((void *)tramp, &opcode, 2);
>
On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote:
> diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
> index 8026d176f25c..d3869295b88d 100644
> --- a/arch/x86/kernel/static_call.c
> +++ b/arch/x86/kernel/static_call.c
> @@ -9,13 +9,21 @@
>
> void static_c
90 matches
Mail list logo
