linux-kernel - Re: [PATCH] x86: remove unneeded endless loop in BUG()

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 19 Feb 2009 12:29:48 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Petr Tesarik <ptesarik@...e.cz>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: remove unneeded endless loop in BUG()

Ingo Molnar wrote:
> 
> the problem is that the DO_BUG() will generate the u2d 
> instruction into a random place where GCC puts it. It certainly 
> wont be in the place where the __bug_table logic above expects 
> it.
> 
> The result will be cryptic crashes instead of a clean BUG 
> message assert.
> 

I went and talked to H.J. Lu about this.

He said __builtin_trap(); is functionally treated as an asm volatile, 
and that it is most likely impossible that gcc could do anything wrong 
here (he did specifically state that nothing can move across the asm 
volatile, and there are no data dependencies between the asm volatile 
and the __builtin_trap).

He also agreed that the right way to do this is __builtin_not_reached(), 
and I promised to submit a feature request for this for a future version 
of gcc.

Given that, I would suggest we back out the patch, and that when 
__builtin_not_reached(); is supported, we can simply do:

#if __GNUC__ is recent enough
# define not_reached() __builtin_not_reached()
#else
# define not_reached() for(;;)
#endif

OK?

	-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/