From: "H. Peter Anvin" <hpa@zytor.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Steven Rostedt <rostedt@goodmis.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Borislav Petkov <bp@alien8.de>, Andi Kleen <andi@firstfloor.org>
Subject: Re: [RFC] x86_64: A real proposal for iret-less return to kernel
Date: Wed, 21 May 2014 16:03:13 -0700 [thread overview]
Message-ID: <537D30B1.9030407@zytor.com> (raw)
In-Reply-To: <CALCETrU-F_-p8yLRE+z0ULHTr8yhiet4owOW-1tuxT9TQFtTGQ@mail.gmail.com>
On 05/21/2014 03:41 PM, Andy Lutomirski wrote:
>>
>> I think you are onto something here.
>>
>> In particular, the key observation here is that inside the kernel, we
>> can never *both* have an invalid stack *and* be inside an NMI, #MC or
>> #DB handler, even if nested.
>
> Except for espfix :)
Argh. Yes, I got that wrong... it isn't really about being inside NMI,
#MC or #DB, but rather being on those respective stacks. If you are on
the espfix stack you are on your way back to userspace OR (and this gets
really, really ugly) you took an NMI/MC/DB after a SYSCALL executed in
16-bit mode, but even then you are in the kernel entry/exit code and
re-enabling NMI is fine.
>> Now, does this prevent us from using RET in the common case? I'm not
>> sure it is a huge loss since kernel-to-kernel is relatively rare.
>
> I don't think so. The most common case should be plain old interrupts
> and I suspect that #PF is a distant second.
>
> In any event, plain old interrupts and #PF are non-IST interrupts and
> they should be unconditionally safe for RET
-hpa
next prev parent reply other threads:[~2014-05-21 23:03 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-21 0:53 [RFC] x86_64: A real proposal for iret-less return to kernel Andy Lutomirski
2014-05-21 2:27 ` Steven Rostedt
2014-05-21 2:33 ` H. Peter Anvin
2014-05-21 2:39 ` Andy Lutomirski
2014-05-21 9:46 ` Borislav Petkov
2014-05-21 15:21 ` Andy Lutomirski
2014-05-21 16:30 ` Borislav Petkov
2014-05-21 17:52 ` Andy Lutomirski
2014-05-21 18:07 ` Borislav Petkov
2014-05-21 12:51 ` Jiri Kosina
2014-05-21 15:21 ` Andy Lutomirski
2014-05-21 16:33 ` Borislav Petkov
2014-05-21 21:25 ` Jiri Kosina
2014-05-21 21:35 ` Andy Lutomirski
2014-05-21 21:48 ` Borislav Petkov
2014-05-21 21:52 ` Andy Lutomirski
2014-05-21 21:55 ` Borislav Petkov
2014-05-21 21:59 ` Jiri Kosina
2014-05-21 21:59 ` Andy Lutomirski
2014-05-21 22:01 ` Luck, Tony
2014-05-21 22:13 ` Andy Lutomirski
2014-05-21 22:17 ` Borislav Petkov
2014-05-21 22:20 ` Andy Lutomirski
2014-05-21 22:36 ` Borislav Petkov
2014-05-21 22:18 ` Luck, Tony
2014-05-21 22:24 ` Andy Lutomirski
2014-05-21 22:32 ` Luck, Tony
2014-05-21 22:39 ` Andy Lutomirski
2014-05-21 22:48 ` Borislav Petkov
2014-05-21 22:52 ` Andy Lutomirski
2014-05-21 23:02 ` Borislav Petkov
2014-05-21 23:05 ` Luck, Tony
2014-05-21 23:07 ` Andy Lutomirski
2014-05-21 23:19 ` Luck, Tony
2014-05-21 23:30 ` Linus Torvalds
2014-05-21 23:40 ` Luck, Tony
2014-05-21 23:51 ` Borislav Petkov
2014-05-22 0:03 ` Linus Torvalds
2014-05-22 8:50 ` Borislav Petkov
2014-05-22 0:05 ` Andy Lutomirski
2014-05-21 21:37 ` Linus Torvalds
2014-05-21 21:43 ` Borislav Petkov
2014-05-21 21:45 ` H. Peter Anvin
2014-05-21 21:47 ` Andy Lutomirski
2014-05-21 21:54 ` Borislav Petkov
2014-05-21 22:00 ` H. Peter Anvin
2014-05-21 22:11 ` Borislav Petkov
2014-05-21 22:13 ` H. Peter Anvin
2014-05-21 22:21 ` Borislav Petkov
2014-05-26 10:18 ` [PATCH] x86, MCE: Flesh out when to panic comment Borislav Petkov
2014-05-26 10:51 ` Jiri Kosina
2014-05-26 11:06 ` Borislav Petkov
2014-05-26 16:47 ` Andy Lutomirski
2014-05-26 17:51 ` Borislav Petkov
2014-05-26 17:59 ` Andy Lutomirski
2014-05-27 21:53 ` Luck, Tony
2014-05-27 22:24 ` Borislav Petkov
2014-05-27 22:33 ` Luck, Tony
2014-05-21 21:50 ` [RFC] x86_64: A real proposal for iret-less return to kernel Jiri Kosina
2014-05-21 18:11 ` Andy Lutomirski
2014-05-21 22:36 ` H. Peter Anvin
2014-05-21 22:41 ` Andy Lutomirski
2014-05-21 23:03 ` H. Peter Anvin [this message]
2014-05-21 22:25 ` Andi Kleen
2014-05-21 22:32 ` Andy Lutomirski
2014-05-21 22:33 ` Linus Torvalds
2014-05-21 23:23 ` Andi Kleen
2014-05-21 23:34 ` Linus Torvalds
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=537D30B1.9030407@zytor.com \
--to=hpa@zytor.com \
--cc=andi@firstfloor.org \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/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.