linux-kernel - Re: [PATCH] ARM: Convert BUG() to use unreachable()

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: <20091217183517.GC10707@synopsys.com>
Date:	Thu, 17 Dec 2009 10:35:17 -0800
From:	Joe Buck <Joe.Buck@...opsys.COM>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Richard Guenther <richard.guenther@...il.com>,
	David Daney <ddaney@...iumnetworks.com>,
	"gcc@....gnu.org" <gcc@....gnu.org>,
	Jamie Lokier <jamie@...reable.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
Subject: Re: [PATCH] ARM: Convert BUG() to use unreachable()

On Thu, Dec 17, 2009 at 10:17:18AM -0800, Russell King - ARM Linux wrote:
> > It shouldn't as *(int *)0 = 0; might trap.  But if you want to be sure
> > use
> >    __builtin_trap ();
> > instead for the whole sequence (the unreachable is implied then).
> > GCC choses a size-optimal trap representation for your target then.
> 
> How is "size-optimal trap" defined?  The point of "*(int *)0 = 0;" is
> to cause a NULL pointer dereference which is trapped by the kernel to
> produce a full post mortem and backtrace which is easily recognised
> as a result of this code.

With something like __builtin_trap, the compiler knows that your intent
is to cause a trap.  But it's asking for trouble, and for future
flame wars between kernel developers and gcc developers, to put in
sequences that happen to do the right thing if the compiler does
no optimizations whatsoever, but that might be messed up by optimizations
because they are code sequences whose behavior is undefined.

Besides, didn't I see a whole bunch of kernel security patches related
to null pointer dereferences lately?  If page 0 can be mapped, you
suddenly won't get your trap.
--
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/