mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Andi Kleen <andi@firstfloor.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [RFC] x86_64: A real proposal for iret-less return to kernel
Date: Wed, 21 May 2014 20:07:19 +0200	[thread overview]
Message-ID: <20140521180718.GN21205@pd.tnic> (raw)
In-Reply-To: <CALCETrXP1GSfgObP4DLbG+Reu3a4g=26aoOpe9jfUtt4_bzCfQ@mail.gmail.com>

On Wed, May 21, 2014 at 10:52:01AM -0700, Andy Lutomirski wrote:
> I think that some of these exceptions are synchronous things (e.g.
> int3 or page faults) that happen because the kernel caused them.
> 
> Anyway, going through the list:
> 
> Reset, INIT, and stpclk ought to be irrelevant -- we don't handle them anyway.

Yeah.

> SMI is already supposedly correct wrt nesting inside NMI.

It better be. :)

> Debug register stuff should be handled in my outline.  Hopefully
> correctly :)  We need to make sure that no breakpoints trip before the
> nmi count is incremented, but that should be straightforward as long
> as we don't do ridiculous things like poking at userspace addresses.
> I don't know how kgdb/kdb fits in -- if someone sets a watchpoint on a
> kernel address (e.g. the nesting count) or enables single-stepping,
> we'll mess up.
> 
> 
> It may pay to bump the nesting count inside the #DB and #BP handlers
> and to check the RIP that we're returning to,

Right, at a first glance, all those higher prio exceptions' nesting
count could be nicely dealt with in those paranoidzeroentry* macros.

> but that starts to look ugly, and we have to be careful about NMI,
> immediate breakpoint, and them immediate MCE.

Btw, hpa just confirmed that exceptions are never deferred and thus can
happen while the NMI nahdler runs. Which means, we should defensively
prepare for NMI handlers being interrupted at any point.

> I'd rather just be able to say that there are some very short windows
> in which a debug or breakpoint exception will never happen.

Sounds perfectly fine to me.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

  reply	other threads:[~2014-05-21 18:07 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-21  0:53 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 [this message]
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
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=20140521180718.GN21205@pd.tnic \
    --to=bp@alien8.de \
    --cc=andi@firstfloor.org \
    --cc=hpa@zytor.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome