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

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


* Petr Tesarik <ptesarik@...e.cz> wrote:

> Ingo Molnar píše v Čt 19. 02. 2009 v 16:35 +0100:
> >[...]
> > * Jeremy Fitzhardinge <jeremy@...p.org> wrote:
> > 
> > > Ingo Molnar wrote:
> > >> * Petr Tesarik <ptesarik@...e.cz> wrote:
> > >>
> > >>   
> > >>> Ingo Molnar píše v Čt 19. 02. 2009 v 13:47 +0100:
> > >>>     
> > >>>> so GCC should be fixed and improved here, on several levels.
> > >>>>       
> > >>> Agree.
> > >>>
> > >>> But it takes some time, even if we start pushing right now. What's 
> > >>> your suggestion for the meantime? Keep the dummy jmp? And in case 
> > >>> anybody is concerned about saving every byte in the text section, 
> > >>> they can apply my dirty patch?
> > >>>
> > >>> Actually, this doesn't sound too bad.
> > >>>     
> > >>
> > >> yeah. Please forward the problem to the appropriate GCC list in any 
> > >> case.
> > >>
> > >>   
> > >
> > > I think the official answer for this case is to use __builtin_trap.  But:
> > >
> > > -- Built-in Function: void __builtin_trap (void)
> > >     This function causes the program to exit abnormally.  GCC
> > >     implements this function by using a target-dependent mechanism
> > >     (such as intentionally executing an illegal instruction) or by
> > >     calling `abort'.  ***The mechanism used may vary from release to
> > >     release so you should not rely on any particular implementation.***
> > >
> > > which in principle is hard for us to make use of.  In practice I think  
> > > it has always been ud2a on x86.
> > 
> > could we just do:
> > 
> > 	__builtin_trap();
> > 	for (;;);
> 
> I'm afraid that's not the point of the exercise. I'm trying to 
> trim BUG() to two bytes, while still making sure that the 
> Illegal Opcode exception is generated at the exact code point, 
> so we can track it down using the info in __bug_table. If 
> __builtin_trap() ever translates to anything else than ud2a in 
> the above code snippet, there will be no BUG reported. 
> Instead, the CPU that encountered the BUG() will burn CPU 
> cycles forever without any apparent reason.

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.)

	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/