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
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
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
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'
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
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
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
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
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, 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
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
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, 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
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
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
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
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 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
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
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, ...)
> > > {
> > >
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, ...)
> > > {
> > >
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
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
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
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
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 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
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
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
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
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
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
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,
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
> 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
> 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
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
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
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
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
> 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
> 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
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, 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
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
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, 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
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
> 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 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
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
1 - 100 of 177 matches
Mail list logo
