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 13:19:31 +0100
From:	Petr Tesarik <ptesarik@...e.cz>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Definition of BUG on x86

Ingo Molnar píše v Čt 19. 02. 2009 v 13:10 +0100:
> * Petr Tesarik <ptesarik@...e.cz> wrote:
> 
> > So, the only method I could invent was using gas macros. It 
> > works but is quite ugly, because it relies on the actual 
> > assembler instruction which is generated by the compiler. Now, 
> > AFAIK gcc has always translated "for(;;)" into a jump to self, 
> > and that with any conceivable compiler options, but I don't 
> > know anything about Intel cc.
> 
> > +static inline __noreturn void discarded_jmp(void)
> > +{
> > +	asm volatile(".macro jmp target\n"
> > +		     "\t.purgem jmp\n"
> > +		     ".endm\n");
> > +	for (;;) ;
> > +}
> 
> hm, that's very fragile.
> 
> Why not just:
> 
>  static inline __noreturn void x86_u2d(void)
>  {
> 	asm volatile("u2d\n");
>  }
> 
> If GCC emits a bogus warning about _that_, then it's a bug in 
> the compiler that should be fixed.

I wouldn't call it a bug. The compiler has no idea about what the inline
assembly actualy does. So it cannot recognize that the ud2 instruction
does not return (which BTW might not even be the case, depending on the
implementation of the Invalid Opcode exception).

So, yes, it would be very nice if we had a way of telling the compiler
that a particular asm() statement is in fact a jump somewhere else. I
don't care about the syntax, I could even imagine something like:

  asm("some code" : : : "ip");  /* clobbers the instruction pointer */

Alternatively, if we could turn that particular warning off, I'd go for
it, but having a build spit warnings like:

/usr/src/linux-2.6/arch/x86/include/asm/bug.h:10: warning: 'noreturn' function does return

for each file that includes <asm/bug.h> in some way is _TOO_ annoying,
sorry.

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/