linux-kernel - Re: Definition of BUG on x86

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

Date:	Thu, 19 Feb 2009 21:26:47 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Petr Tesarik <ptesarik@...e.cz>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Definition of BUG on x86


* H. Peter Anvin <hpa@...or.com> wrote:

> Jeremy Fitzhardinge wrote:
>> Ingo Molnar wrote:
>>> Well, the important question is thatGCC will optimize out whatever  
>>> comes after the __builtin_trap(), right? To guarantee an assert we 
>>> can do something like:
>>>
>>>      __builtin_trap();
>>>     panic("should never get here");
>>>
>>> to guarantee a message. (But realistically GCC will at most generate 
>>> a build error.)
>>>   
>>
>> Ah, right, I remember the problem.  There's no guaranteed way of 
>> getting the address of the ud2a instruction __builtin_trap generates to 
>> put it into the bug table.
>>
>
> Did we actually run into any instance where that failed?
>
> It's true that it's not guaranteed, but it seems highly 
> unlikely that it would happen in real life.  We *could* do a 
> forward search at that point, that should catch the vast 
> majority of the failing cases, again, but once again there are 
> no guarantees.
>
> I guess I should ask the gcc people...

The whole thing is borderline anyway (the win is small), and the 
combination of relying on __builtin_trap() [which is documented 
as a non-stable interface], and the reliance on basic block 
non-ordering.

Another complication is that this is _debug_ code - i.e. if 
there's a rare bug here we'll only see it if a bug triggers 
there - which is very rare in itself.

So i'm rather uneasy to rely on GCC to this level. They should 
allow to pass __noreturn to asm()s - that's a far cleaner 
approach.

	Ingo
--
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/