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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 24 Feb 2017 09:31:15 +0100
From:   Peter Zijlstra <>
To:     Ingo Molnar <>
Cc:     Arjan van de Ven <>,
        Thomas Gleixner <>,
        "H. Peter Anvin" <>,,,,,,
        Andrew Morton <>
Subject: Re: [PATCH] x86: Implement __WARN using UD0

On Fri, Feb 24, 2017 at 08:43:25AM +0100, Ingo Molnar wrote:
> The only high level question is whether we trust the trap machinery to generate 
> WARN_ON()s. I believe we do.
> BTW.: why not use INT3 instead of all these weird #UD opcodes? It's a single byte 
> opcode and we can do a quick exception table search in do_debug(). This way we'll 
> also have irqs disabled which might help getting the message out before any irq 
> handler comes in and muddies the waters.
> In a sense WARN_ON()s and BUG_ON()s can be considered permanently installed 
> in-line kprobes, with a special, built-in handler.

I've actually been looking into that. There's a bunch of 'fun' details
that I've been checking, but I think I can make that happen.

My initial patch extended the existing UD2 BUG trap to include the WARN,
this is what many other architectures already do. Arjan then complained
that some emulators terminate on UD2 and could I please not use that for
WARN, at which point Borislav called my attention to UD0/UD1.

So I made the UD0 change and posted (fwiw, there's a lost refresh in the
patch I posted and it will not actually work).

I think I'll post an update of said patch and then attempt to do the
INT3 thing in a later patch -- that will require at least one new knob
in the generic BUG code ...

> BTW. #2: side note, GCC generated crap code here. Why didn't it do:

I've seen GCC do 'wonderful' things the past few weeks. Absolutely mind
boggling stuff.

Powered by blists - more mailing lists