Confirm the semantic of GCC extension "Conditionals with Omitted Operands"

Nathan Sidwell nathan@acm.org
Wed Jul 1 15:53:05 GMT 2020


On 7/1/20 10:11 AM, Gong, Sishuai via Gcc wrote:
> Hello,
> 
> Hope this mail finds you well. I am writing this to ask about one extension in GCC, which is “Conditionals with Omitted Operands”.
> 
>  From the document at https://gcc.gnu.org/onlinedocs/gcc/Conditionals.html , we learn that this extension could be useful in terms of avoiding the side effects of recomputing. However, we recently observed a case in the Linux kernel, where the kernel develops are using this extension but compiling their code with certain optimizations disabled may lead to a concurrency vulnerability. The general idea of this problem is, for a line of code leveraging “Conditionals with Omitted Operands", GCC, with fewer optimizations, could generate a disassembly contains two memory read to the same object. One is for checking the value in the first operand in the ternary expression and another is for the second operand, which is omitted in order to leverage this extension. Thus, another thread could update the object between the two read and lead to inconsistent behavior. We are not sure if this is a problem with GCC or the kernel developers should be aware of this vulnerability. Hope you could give us some hints.
> 
> Here I put a simple program that I hope could explain this problem.
> #include<stdio.h>
> #include<stdlib.h>
> 
>   unsigned int hello(int *const *a)
>   {
>       return (unsigned int)((unsigned int)*a & 0xFE) ? : 0x123;
>   }

because a's type is 'int *', there are no changes in semantics, at the C 
abstract machine level, for accessing *a any number of times.  Thus 
depending on a specific number of accesses is unreliable.

nathan

-- 
Nathan Sidwell


More information about the Gcc mailing list