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]

Message-Id: <1235062515.15053.94.camel@nathan.suse.cz>
Date:	Thu, 19 Feb 2009 17:55:15 +0100
From:	Petr Tesarik <ptesarik@...e.cz>
To:	Ingo Molnar <mingo@...e.hu>
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

Ingo Molnar píše v Čt 19. 02. 2009 v 17:16 +0100:
> * 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");

Yes, perfect, then I vote for this:

	__builtin_trap();
	printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __func__);
	panic("BUG!");

(copied from include/asm-generic/bug.h)

Then the worst thing GCC folks might invent would be using the ud2b
opcode instead of ud2a, but I think the bug table is searched for every
die() invocation nowadays, so it doesn't depend on seeing the
0f 0b sequence at the point of the failure, does it?

And even if GCC decides to insert one or more _valid_ instructions
before the invalid one, we'll start getting reports with 
"[verbose debug info unavailable]". If, instead, they start calling
abort(), we'll get build errors.

Last thing -- what about Intel cc?

Petr Tesarik

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