All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <sean.j.christopherson@intel.com>
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 15:08:15 -0700	[thread overview]
Message-ID: <20190429220814.GF31379@linux.intel.com> (raw)
In-Reply-To: <CAHk-=wjyyKDv-WZLXZbVD=V05p2X7eg74z2SpR4TQTxN9JLq4Q@mail.gmail.com>

On Mon, Apr 29, 2019 at 01:16:10PM -0700, Linus Torvalds wrote:
> On Mon, Apr 29, 2019 at 12:02 PM Linus Torvalds
> <torvalds@linux-foundation.org> 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 simply the official Intel instruction
> docs for "STI":
> 
>     The IF flag and the STI and CLI instructions do not prohibit the
>     generation of exceptions and NMI interrupts. NMI interrupts (and
>     SMIs) may be blocked for one macroinstruction following an STI.
> 
> note the "may be blocked". As mentioned, that's just one option for
> not having NMI break the STI shadow guarantee, but it's clearly one
> that Intel has done at times, and clearly even documents as having
> done so.
> 
> There is absolutely no question that the sti shadow is real, and that
> people have depended on it for _decades_. It would be a horrible
> errata if the shadow can just be made to go away by randomly getting
> an NMI or SMI.

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 will effectively break the shadow on its IRET.

All other (modern) Intel uArchs block NMI in the shadow and also enforce
STI_BLOCKING==0 when injecting an NMI via VM-Enter, i.e. prevent a VMM
from breaking the shadow so long as the VMM preserves the shadow info.

KVM is generally ok with respect to STI blocking, but ancient versions
didn't migrate STI blocking and there's currently a hole where
single-stepping a guest (from host userspace) could drop STI_BLOCKING
if a different VM-Exit occurs between the single-step #DB VM-Exit and the
instruction in the shadow.  Though "don't do that" may be a reasonable
answer in that case.

WARNING: multiple messages have this Message-ID (diff)
From: sean.j.christopherson at intel.com (Sean Christopherson)
Subject: [PATCH 3/4] x86/ftrace: make ftrace_int3_handler() not to skip fops invocation
Date: Mon, 29 Apr 2019 15:08:15 -0700	[thread overview]
Message-ID: <20190429220814.GF31379@linux.intel.com> (raw)
In-Reply-To: <CAHk-=wjyyKDv-WZLXZbVD=V05p2X7eg74z2SpR4TQTxN9JLq4Q@mail.gmail.com>

On Mon, Apr 29, 2019 at 01:16:10PM -0700, Linus Torvalds wrote:
> On Mon, Apr 29, 2019 at 12:02 PM Linus Torvalds
> <torvalds at linux-foundation.org> 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 simply the official Intel instruction
> docs for "STI":
> 
>     The IF flag and the STI and CLI instructions do not prohibit the
>     generation of exceptions and NMI interrupts. NMI interrupts (and
>     SMIs) may be blocked for one macroinstruction following an STI.
> 
> note the "may be blocked". As mentioned, that's just one option for
> not having NMI break the STI shadow guarantee, but it's clearly one
> that Intel has done at times, and clearly even documents as having
> done so.
> 
> There is absolutely no question that the sti shadow is real, and that
> people have depended on it for _decades_. It would be a horrible
> errata if the shadow can just be made to go away by randomly getting
> an NMI or SMI.

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 will effectively break the shadow on its IRET.

All other (modern) Intel uArchs block NMI in the shadow and also enforce
STI_BLOCKING==0 when injecting an NMI via VM-Enter, i.e. prevent a VMM
from breaking the shadow so long as the VMM preserves the shadow info.

KVM is generally ok with respect to STI blocking, but ancient versions
didn't migrate STI blocking and there's currently a hole where
single-stepping a guest (from host userspace) could drop STI_BLOCKING
if a different VM-Exit occurs between the single-step #DB VM-Exit and the
instruction in the shadow.  Though "don't do that" may be a reasonable
answer in that case.

WARNING: multiple messages have this Message-ID (diff)
From: sean.j.christopherson@intel.com (Sean Christopherson)
Subject: [PATCH 3/4] x86/ftrace: make ftrace_int3_handler() not to skip fops invocation
Date: Mon, 29 Apr 2019 15:08:15 -0700	[thread overview]
Message-ID: <20190429220814.GF31379@linux.intel.com> (raw)
Message-ID: <20190429220815.DAoelM3vSwtPxaf1pu6zMfIIa7rwH8wbnFoJeX2S9BY@z> (raw)
In-Reply-To: <CAHk-=wjyyKDv-WZLXZbVD=V05p2X7eg74z2SpR4TQTxN9JLq4Q@mail.gmail.com>

On Mon, Apr 29, 2019@01:16:10PM -0700, Linus Torvalds wrote:
> On Mon, Apr 29, 2019 at 12:02 PM Linus Torvalds
> <torvalds@linux-foundation.org> 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 simply the official Intel instruction
> docs for "STI":
> 
>     The IF flag and the STI and CLI instructions do not prohibit the
>     generation of exceptions and NMI interrupts. NMI interrupts (and
>     SMIs) may be blocked for one macroinstruction following an STI.
> 
> note the "may be blocked". As mentioned, that's just one option for
> not having NMI break the STI shadow guarantee, but it's clearly one
> that Intel has done at times, and clearly even documents as having
> done so.
> 
> There is absolutely no question that the sti shadow is real, and that
> people have depended on it for _decades_. It would be a horrible
> errata if the shadow can just be made to go away by randomly getting
> an NMI or SMI.

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 will effectively break the shadow on its IRET.

All other (modern) Intel uArchs block NMI in the shadow and also enforce
STI_BLOCKING==0 when injecting an NMI via VM-Enter, i.e. prevent a VMM
from breaking the shadow so long as the VMM preserves the shadow info.

KVM is generally ok with respect to STI blocking, but ancient versions
didn't migrate STI blocking and there's currently a hole where
single-stepping a guest (from host userspace) could drop STI_BLOCKING
if a different VM-Exit occurs between the single-step #DB VM-Exit and the
instruction in the shadow.  Though "don't do that" may be a reasonable
answer in that case.

  reply	other threads:[~2019-04-29 22:08 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
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 [this message]
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=20190429220814.GF31379@linux.intel.com \
    --to=sean.j.christopherson@intel.com \
    --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=luto@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.