From: Peter Zijlstra <peterz@infradead.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@kernel.org>,
Arjan van de Ven <arjan@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
bp@alien8.de, jpoimboe@redhat.com, richard.weinberger@gmail.com,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] x86: Implement __WARN using UD0
Date: Fri, 24 Feb 2017 11:41:33 +0100 [thread overview]
Message-ID: <20170224104133.GO6515@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <21ac6e53-2fcd-52e9-e72d-9faf7da14d1e@zytor.com>
On Fri, Feb 24, 2017 at 01:53:27AM -0800, H. Peter Anvin wrote:
> On 02/24/17 01:15, Ingo Molnar wrote:
> >
> > * hpa@zytor.com <hpa@zytor.com> wrote:
> >
> >> Incidentally, as an alternative to a #UD, int $9 could be an alternative
> >> (exception vector 9 was discontinued with the 486.)
> >
> > With thousands of call sites a one byte opcode would be preferred, that's why INT3
> > is so nice.
> >
>
> Yes, but using INT3 would bugger up debuggers.
So I've been looking into this, in general debuggers will refuse to poke
INT3 on top of INT3 (sane and obvious behaviour).
Also, we'd run any actual handlers before fixup_bug(), the only thing
here is that we need to also do fixup_bug() if the instruction pointer
isn't changed. This would allow debuggers to effectively stack on top
of the already present breakpoint.
Optimized kprobes will make sure to not clobber INT3 (although it will
happily clobber anything else from __ex_table[]).
The only other point is that currently report_bug() relies on
is_valid_bugaddr() to tell if the instruction is 'good', but then
reports a BUG if there is no entry in __bug_table[]. We'd have to change
that to be strict and assume __bug_table[] is complete, and report
BUG_TRAP_TYPE_NONE when there is no __bug_table[] entry, this would also
avoid the need for is_valid_bugaddr().
So yes, its tricky but it could be done. A new single byte #UD
instruction would be much nicer though.
next prev parent reply other threads:[~2017-02-24 11:44 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-23 13:28 [PATCH] x86: Implement __WARN using UD0 Peter Zijlstra
2017-02-23 14:09 ` Peter Zijlstra
2017-02-23 14:59 ` Peter Zijlstra
2017-02-23 15:09 ` hpa
2017-02-23 15:23 ` Peter Zijlstra
2017-02-23 15:32 ` hpa
2017-02-23 16:03 ` Borislav Petkov
2017-02-23 14:12 ` Josh Poimboeuf
2017-02-23 14:17 ` Borislav Petkov
2017-02-23 14:36 ` Peter Zijlstra
2017-02-23 14:14 ` Arjan van de Ven
2017-02-23 14:57 ` Peter Zijlstra
2017-02-24 7:43 ` Ingo Molnar
2017-02-24 8:31 ` Peter Zijlstra
2017-02-24 9:06 ` hpa
2017-02-24 9:11 ` hpa
2017-02-24 9:15 ` Ingo Molnar
2017-02-24 9:46 ` Borislav Petkov
2017-02-24 9:52 ` H. Peter Anvin
[not found] ` <21ac6e53-2fcd-52e9-e72d-9faf7da14d1e@zytor.com>
2017-02-24 10:41 ` Peter Zijlstra [this message]
2017-02-25 10:38 ` Borislav Petkov
2017-02-25 17:55 ` hpa
2017-02-25 19:38 ` Borislav Petkov
2017-02-25 20:04 ` hpa
2017-02-25 20:29 ` Borislav Petkov
2017-02-24 11:16 ` [PATCH -v2] " Peter Zijlstra
2017-02-25 8:19 ` [RFC][PATCH] bug: Add _ONCE logic to report_bug() Peter Zijlstra
2017-02-25 9:18 ` Ingo Molnar
2017-02-25 9:44 ` Peter Zijlstra
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=20170224104133.GO6515@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=arjan@linux.intel.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=richard.weinberger@gmail.com \
--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