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
