linux-kernel - Re: [PATCH] x86: Implement _

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 24 Feb 2017 11:41:33 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     "H. Peter Anvin" <hpa@...or.com>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
        bp@...en8.de, jpoimboe@...hat.com, richard.weinberger@...il.com,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] x86: Implement __WARN using UD0

On Fri, Feb 24, 2017 at 01:53:27AM -0800, H. Peter Anvin wrote:
> On 02/24/17 01:15, Ingo Molnar wrote:
> > 
> > * hpa@...or.com <hpa@...or.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.