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]

Date:	Thu, 17 Dec 2009 15:01:20 +0000
From:	Jamie Lokier <jamie@...reable.org>
To:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
Cc:	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	David Daney <ddaney@...iumnetworks.com>
Subject: Re: [PATCH] ARM: Convert BUG() to use unreachable()

Uwe Kleine-König wrote:
> Use the new unreachable() macro instead of for(;;);
>  	*(int *)0 = 0;
>  
>  	/* Avoid "noreturn function does return" */
> -	for (;;);
> +	unreachable();

Will GCC-4.5 remove ("optimise away") the *(int *)0 = 0 because it
knows the branch of the code leading to unreachable can never be reached?

If GCC-4.5 does not, are you sure a future version of GCC will never
remove it?  In other words, is __builtin_unreachable() _defined_ in
such a way that it cannot remove the previous assignment?

We have seen problems with GCC optimising away important tests for
NULL pointers in the kernel, due to similar propagation of "impossible
to occur" conditions, so it's worth checking with GCC people what the
effect of this one would be.

In C, there is a general theoretical problem with back-propagation of
optimisations from code with undefined behaviour.  In the case of
__builtin_unreachable(), it would depend on all sorts of unclearly
defined semantics whether it can remove a preceding *(int *)0 = 0.

I'd strongly suggest asking on the GCC list.  (I'd have mentioned this
earlier, if I'd known about the patch for other architectures).

The documentation for __builtin_unreachable() only says the program is
undefined if control flow reaches it.  In other words, it does not say
what effect it can have on previous instructions, and I think it's
quite likely that it has not been analysed in a case like this.

One thing that would give me a lot more confidence, because the GCC
documentation does mention asm(), is this:

>       *(int *)0 = 0;
>       /* Ensure unreachableness optimisations cannot propagate back. *I/
>       __asm__ volatile("");
>       /* Avoid "noreturn function does return" */
>       unreachable();

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