From: Andy Lutomirski <luto@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Lutomirski <luto@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Peter Zijlstra <peterz@infradead.org>,
Nicolai Stange <nstange@suse.de>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
"the arch/x86 maintainers" <x86@kernel.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Jiri Kosina <jikos@kernel.org>, Miroslav Benes <mbenes@suse.cz>,
Petr Mladek <pmladek@suse.com>,
Joe Lawrence <joe.lawrence@redhat.com>,
Shuah Khan <shuah@kernel.org>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Tim Chen <tim.c.chen@linux.intel.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Mimi Zohar <zohar@linux.ibm.com>, Juergen Gross <jgross@suse.com>,
Nick Desaulniers <ndesaulniers@google.com>,
Nayna Jain <nayna@linux.ibm.com>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Joerg Roedel <jroedel@suse.de>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
live-patching@vger.kernel.org,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>
Subject: Re: [PATCH 3/4] x86/ftrace: make ftrace_int3_handler() not to skip fops invocation
Date: Mon, 29 Apr 2019 11:56:54 -0700 [thread overview]
Message-ID: <CALCETrWELBCK-kqX5FCEDVUy8kCT-yVu7m_7Dtn=GCsHY0Du5A@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=whtt4K2f0KPtG-4Pykh3FK8UBOjD8jhXCUKB5nWDj_YRA@mail.gmail.com>
On Mon, Apr 29, 2019 at 11:53 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
>
> On Mon, Apr 29, 2019, 11:42 Andy Lutomirski <luto@kernel.org> 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. I can think of three solutions:
>
>
> No, because either the sti shadow disables nmi too (that's the case on some CPUs at least) or the iret from nmi does.
>
> Otherwise you could never trust the whole sti shadow thing - and it very much is part of the architecture.
>
Is this documented somewhere? And do you actually believe that this
is true under KVM, Hyper-V, etc? As I recall, Andrew Cooper dug in to
the way that VMX dealt with this stuff and concluded that the SDM was
blatantly wrong in many cases, which leads me to believe that Xen
HVM/PVH is the *only* hypervisor that gets it right.
Steven's point about batched updates is quite valid, though. My
personal favorite solution to this whole mess is to rework the whole
thing so that the int3 handler simply returns and retries and to
replace the sync_core() broadcast with an SMI broadcast. I don't know
whether this will actually work on real CPUs and on VMs and whether
it's going to crash various BIOSes out there.
WARNING: multiple messages have this Message-ID (diff)
From: luto at kernel.org (Andy Lutomirski)
Subject: [PATCH 3/4] x86/ftrace: make ftrace_int3_handler() not to skip fops invocation
Date: Mon, 29 Apr 2019 11:56:54 -0700 [thread overview]
Message-ID: <CALCETrWELBCK-kqX5FCEDVUy8kCT-yVu7m_7Dtn=GCsHY0Du5A@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=whtt4K2f0KPtG-4Pykh3FK8UBOjD8jhXCUKB5nWDj_YRA@mail.gmail.com>
On Mon, Apr 29, 2019 at 11:53 AM Linus Torvalds
<torvalds at linux-foundation.org> wrote:
>
>
>
> On Mon, Apr 29, 2019, 11:42 Andy Lutomirski <luto at kernel.org> 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. I can think of three solutions:
>
>
> No, because either the sti shadow disables nmi too (that's the case on some CPUs at least) or the iret from nmi does.
>
> Otherwise you could never trust the whole sti shadow thing - and it very much is part of the architecture.
>
Is this documented somewhere? And do you actually believe that this
is true under KVM, Hyper-V, etc? As I recall, Andrew Cooper dug in to
the way that VMX dealt with this stuff and concluded that the SDM was
blatantly wrong in many cases, which leads me to believe that Xen
HVM/PVH is the *only* hypervisor that gets it right.
Steven's point about batched updates is quite valid, though. My
personal favorite solution to this whole mess is to rework the whole
thing so that the int3 handler simply returns and retries and to
replace the sync_core() broadcast with an SMI broadcast. I don't know
whether this will actually work on real CPUs and on VMs and whether
it's going to crash various BIOSes out there.
WARNING: multiple messages have this Message-ID (diff)
From: luto@kernel.org (Andy Lutomirski)
Subject: [PATCH 3/4] x86/ftrace: make ftrace_int3_handler() not to skip fops invocation
Date: Mon, 29 Apr 2019 11:56:54 -0700 [thread overview]
Message-ID: <CALCETrWELBCK-kqX5FCEDVUy8kCT-yVu7m_7Dtn=GCsHY0Du5A@mail.gmail.com> (raw)
Message-ID: <20190429185654.PqG_yVPr8RW7p_6qKywGIaw5BmoxLD60aqf7Gn-wR5A@z> (raw)
In-Reply-To: <CAHk-=whtt4K2f0KPtG-4Pykh3FK8UBOjD8jhXCUKB5nWDj_YRA@mail.gmail.com>
On Mon, Apr 29, 2019 at 11:53 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
>
> On Mon, Apr 29, 2019, 11:42 Andy Lutomirski <luto@kernel.org> 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. I can think of three solutions:
>
>
> No, because either the sti shadow disables nmi too (that's the case on some CPUs at least) or the iret from nmi does.
>
> Otherwise you could never trust the whole sti shadow thing - and it very much is part of the architecture.
>
Is this documented somewhere? And do you actually believe that this
is true under KVM, Hyper-V, etc? As I recall, Andrew Cooper dug in to
the way that VMX dealt with this stuff and concluded that the SDM was
blatantly wrong in many cases, which leads me to believe that Xen
HVM/PVH is the *only* hypervisor that gets it right.
Steven's point about batched updates is quite valid, though. My
personal favorite solution to this whole mess is to rework the whole
thing so that the int3 handler simply returns and retries and to
replace the sync_core() broadcast with an SMI broadcast. I don't know
whether this will actually work on real CPUs and on VMs and whether
it's going to crash various BIOSes out there.
next prev parent reply other threads:[~2019-04-29 18:57 UTC|newest]
Thread overview: 192+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-27 10:06 [PATCH 0/4] x86/ftrace: make ftrace_int3_handler() not to skip fops invocation Nicolai Stange
2019-04-27 10:06 ` Nicolai Stange
2019-04-27 10:06 ` nstange
2019-04-27 10:06 ` [PATCH 1/4] x86/thread_info: introduce ->ftrace_int3_stack member Nicolai Stange
2019-04-27 10:06 ` Nicolai Stange
2019-04-27 10:06 ` nstange
2019-04-28 17:41 ` Andy Lutomirski
2019-04-28 17:41 ` Andy Lutomirski
2019-04-28 17:41 ` luto
2019-04-28 17:51 ` Steven Rostedt
2019-04-28 17:51 ` Steven Rostedt
2019-04-28 17:51 ` rostedt
2019-04-28 18:08 ` Andy Lutomirski
2019-04-28 18:08 ` Andy Lutomirski
2019-04-28 18:08 ` luto
2019-04-28 19:43 ` Steven Rostedt
2019-04-28 19:43 ` Steven Rostedt
2019-04-28 19:43 ` rostedt
2019-04-28 20:56 ` Andy Lutomirski
2019-04-28 20:56 ` Andy Lutomirski
2019-04-28 20:56 ` luto
2019-04-28 21:22 ` Nicolai Stange
2019-04-28 21:22 ` Nicolai Stange
2019-04-28 21:22 ` nstange
2019-04-28 23:27 ` Andy Lutomirski
2019-04-28 23:27 ` Andy Lutomirski
2019-04-28 23:27 ` luto
2019-04-27 10:06 ` [PATCH 2/4] ftrace: drop 'static' qualifier from ftrace_ops_list_func() Nicolai Stange
2019-04-27 10:06 ` Nicolai Stange
2019-04-27 10:06 ` nstange
2019-04-27 10:06 ` [PATCH 3/4] x86/ftrace: make ftrace_int3_handler() not to skip fops invocation Nicolai Stange
2019-04-27 10:06 ` Nicolai Stange
2019-04-27 10:06 ` nstange
2019-04-27 10:26 ` Peter Zijlstra
2019-04-27 10:26 ` Peter Zijlstra
2019-04-27 10:26 ` peterz
2019-04-28 17:38 ` Steven Rostedt
2019-04-28 17:38 ` Steven Rostedt
2019-04-28 17:38 ` rostedt
2019-04-29 18:06 ` Linus Torvalds
2019-04-29 18:06 ` Linus Torvalds
2019-04-29 18:06 ` torvalds
2019-04-29 18:22 ` Linus Torvalds
2019-04-29 18:22 ` Linus Torvalds
2019-04-29 18:22 ` torvalds
2019-04-29 18:42 ` Andy Lutomirski
2019-04-29 18:42 ` Andy Lutomirski
2019-04-29 18:42 ` luto
[not found] ` <CAHk-=whtt4K2f0KPtG-4Pykh3FK8UBOjD8jhXCUKB5nWDj_YRA@mail.gmail.com>
2019-04-29 18:56 ` Andy Lutomirski [this message]
2019-04-29 18:56 ` Andy Lutomirski
2019-04-29 18:56 ` luto
[not found] ` <CAHk-=wgewK4eFhF3=0RNtk1KQjMANFH6oDE=8m=84RExn2gxhw@mail.gmail.com>
[not found] ` <CAHk-=whay7eN6+2gZjY-ybRbkbcqAmgrLwwszzHx8ws3c=S-MA@mail.gmail.com>
2019-04-29 19:24 ` Andy Lutomirski
2019-04-29 19:24 ` Andy Lutomirski
2019-04-29 19:24 ` luto
2019-04-29 20:07 ` Linus Torvalds
2019-04-29 20:07 ` Linus Torvalds
2019-04-29 20:07 ` torvalds
2019-04-30 13:56 ` Peter Zijlstra
2019-04-30 13:56 ` Peter Zijlstra
2019-04-30 13:56 ` peterz
2019-04-30 16:06 ` Linus Torvalds
2019-04-30 16:06 ` Linus Torvalds
2019-04-30 16:06 ` torvalds
2019-04-30 16:33 ` Andy Lutomirski
2019-04-30 16:33 ` Andy Lutomirski
2019-04-30 16:33 ` luto
2019-04-30 17:03 ` Steven Rostedt
2019-04-30 17:03 ` Steven Rostedt
2019-04-30 17:03 ` rostedt
2019-04-30 17:20 ` Steven Rostedt
2019-04-30 17:20 ` Steven Rostedt
2019-04-30 17:20 ` rostedt
2019-04-30 17:49 ` [RFC][PATCH] ftrace/x86: Emulate call function while updating in breakpoint handler Steven Rostedt
2019-04-30 17:49 ` Steven Rostedt
2019-04-30 17:49 ` rostedt
2019-04-30 18:33 ` Linus Torvalds
2019-04-30 18:33 ` Linus Torvalds
2019-04-30 18:33 ` torvalds
2019-04-30 19:00 ` Steven Rostedt
2019-04-30 19:00 ` Steven Rostedt
2019-04-30 19:00 ` rostedt
2019-04-30 21:08 ` Steven Rostedt
2019-04-30 21:08 ` Steven Rostedt
2019-04-30 21:08 ` rostedt
2019-05-01 13:11 ` Peter Zijlstra
2019-05-01 13:11 ` Peter Zijlstra
2019-05-01 13:11 ` peterz
2019-05-01 18:58 ` Steven Rostedt
2019-05-01 18:58 ` Steven Rostedt
2019-05-01 18:58 ` rostedt
2019-05-01 19:03 ` Peter Zijlstra
2019-05-01 19:03 ` Peter Zijlstra
2019-05-01 19:03 ` peterz
2019-05-01 19:03 ` Linus Torvalds
2019-05-01 19:03 ` Linus Torvalds
2019-05-01 19:03 ` torvalds
2019-05-01 19:13 ` Peter Zijlstra
2019-05-01 19:13 ` Peter Zijlstra
2019-05-01 19:13 ` peterz
2019-05-01 19:13 ` Steven Rostedt
2019-05-01 19:13 ` Steven Rostedt
2019-05-01 19:13 ` rostedt
2019-05-01 19:33 ` Jiri Kosina
2019-05-01 19:33 ` Jiri Kosina
2019-05-01 19:33 ` jikos
2019-05-01 19:41 ` Peter Zijlstra
2019-05-01 19:41 ` Peter Zijlstra
2019-05-01 19:41 ` peterz
2019-04-30 21:53 ` [RFC][PATCH v2] " Steven Rostedt
2019-04-30 21:53 ` Steven Rostedt
2019-04-30 21:53 ` rostedt
2019-05-01 1:35 ` Steven Rostedt
2019-05-01 1:35 ` Steven Rostedt
2019-05-01 1:35 ` rostedt
2019-05-01 1:58 ` Linus Torvalds
2019-05-01 1:58 ` Linus Torvalds
2019-05-01 1:58 ` torvalds
2019-05-01 8:26 ` Nicolai Stange
2019-05-01 8:26 ` Nicolai Stange
2019-05-01 8:26 ` nstange
2019-05-01 13:22 ` Steven Rostedt
2019-05-01 13:22 ` Steven Rostedt
2019-05-01 13:22 ` rostedt
2019-04-29 20:16 ` [PATCH 3/4] x86/ftrace: make ftrace_int3_handler() not to skip fops invocation Linus Torvalds
2019-04-29 20:16 ` Linus Torvalds
2019-04-29 20:16 ` torvalds
2019-04-29 22:08 ` Sean Christopherson
2019-04-29 22:08 ` Sean Christopherson
2019-04-29 22:08 ` sean.j.christopherson
2019-04-29 22:22 ` Linus Torvalds
2019-04-29 22:22 ` Linus Torvalds
2019-04-29 22:22 ` torvalds
2019-04-30 0:08 ` Sean Christopherson
2019-04-30 0:08 ` Sean Christopherson
2019-04-30 0:08 ` sean.j.christopherson
2019-04-30 0:45 ` Sean Christopherson
2019-04-30 0:45 ` Sean Christopherson
2019-04-30 0:45 ` sean.j.christopherson
2019-04-30 2:26 ` Linus Torvalds
2019-04-30 2:26 ` Linus Torvalds
2019-04-30 2:26 ` torvalds
2019-04-30 10:40 ` Peter Zijlstra
2019-04-30 10:40 ` Peter Zijlstra
2019-04-30 10:40 ` peterz
2019-04-30 11:17 ` Jiri Kosina
2019-04-30 11:17 ` Jiri Kosina
2019-04-30 11:17 ` jikos
2019-04-29 22:06 ` Linus Torvalds
2019-04-29 22:06 ` Linus Torvalds
2019-04-29 22:06 ` torvalds
2019-04-30 11:18 ` Peter Zijlstra
2019-04-30 11:18 ` Peter Zijlstra
2019-04-30 11:18 ` peterz
2019-04-29 18:52 ` Steven Rostedt
2019-04-29 18:52 ` Steven Rostedt
2019-04-29 18:52 ` rostedt
[not found] ` <CAHk-=wjm93jLtVxTX4HZs6K4k1Wqh3ujjmapqaYtcibVk_YnzQ@mail.gmail.com>
2019-04-29 19:07 ` Steven Rostedt
2019-04-29 19:07 ` Steven Rostedt
2019-04-29 19:07 ` rostedt
2019-04-29 20:06 ` Linus Torvalds
2019-04-29 20:06 ` Linus Torvalds
2019-04-29 20:06 ` torvalds
2019-04-29 20:20 ` Linus Torvalds
2019-04-29 20:20 ` Linus Torvalds
2019-04-29 20:20 ` torvalds
2019-04-29 20:30 ` Steven Rostedt
2019-04-29 20:30 ` Steven Rostedt
2019-04-29 20:30 ` rostedt
2019-04-29 21:38 ` Linus Torvalds
2019-04-29 21:38 ` Linus Torvalds
2019-04-29 21:38 ` torvalds
2019-04-29 22:07 ` Steven Rostedt
2019-04-29 22:07 ` Steven Rostedt
2019-04-29 22:07 ` rostedt
2019-04-30 9:24 ` Nicolai Stange
2019-04-30 9:24 ` Nicolai Stange
2019-04-30 9:24 ` nstange
2019-04-30 10:46 ` Peter Zijlstra
2019-04-30 10:46 ` Peter Zijlstra
2019-04-30 10:46 ` peterz
2019-04-30 13:44 ` Steven Rostedt
2019-04-30 13:44 ` Steven Rostedt
2019-04-30 13:44 ` rostedt
2019-04-30 14:20 ` Peter Zijlstra
2019-04-30 14:20 ` Peter Zijlstra
2019-04-30 14:20 ` peterz
2019-04-30 14:36 ` Steven Rostedt
2019-04-30 14:36 ` Steven Rostedt
2019-04-30 14:36 ` rostedt
2019-04-27 10:06 ` [PATCH 4/4] selftests/livepatch: add "ftrace a live patched function" test Nicolai Stange
2019-04-27 10:06 ` Nicolai Stange
2019-04-27 10:06 ` nstange
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALCETrWELBCK-kqX5FCEDVUy8kCT-yVu7m_7Dtn=GCsHY0Du5A@mail.gmail.com' \
--to=luto@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@redhat.com \
--cc=jroedel@suse.de \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=mingo@redhat.com \
--cc=nayna@linux.ibm.com \
--cc=ndesaulniers@google.com \
--cc=nstange@suse.de \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=shuah@kernel.org \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
--cc=yamada.masahiro@socionext.com \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.