Consensus: data-race freedom as default for glibc code

[Florian Weimer]

On 11/20/2014 07:30 PM, Torvald Riegel wrote:
> "C11 (internally, not exposed via headers):
>
>        * Data-race freedom, as defined by C11 and it's memory model, is
>          the default. A data race is if a possible execution contains two
>          memory accesses, at least one of them is a write, at least one
>          is not an atomic operation, and both are not ordered by
>          happens-before. The transition to data-race freedom will be
>          incremental for existing code, but new code should be
>          data-race-free. If we decide to allow a data race in a certain
>          situation because we reason that it is benign, this must get
>          documented and needs closer inspection, repeatedly (e.g., to
>          check that the generated code is okay). To avoid data races, use
>          locks or atomic operations."
>
> If you disagree with this wording, please let me know.

I agree with the idea, but I don't particularly like the term “data race 
freedom”.  I think what we actually want is that glibc does not rely on 
(technically) undefined data races for correct operation when used 
correctly.  It will still be very easy for programmers to use glibc 
functions in such a way that they suffer from data races, and the 
description above could be interpreted as saying that we want to change 
this.

To absolutely clear, what I mean is that applicable standards typically 
do not require any synchronization at all, and we should not start to 
add synchronization and defensive copies to hide data races (or at least 
some of their consequences).  This not completely unheard of, 
actually—Java code does this a lot, but for slightly different reasons.

Anyway, we should probably avoid code like

   size_t len = strlen(input);
   char *output = malloc(len + 1); // (overflow, error checking omitted)
   strcpy(output, input);

(i.e., pre-computing a size and not checking if it has changed 
afterwards), but copying, say, format strings in formatted output 
because they could change while the formatting function is running, is 
over the top.

-- 
Florian Weimer / Red Hat Product Security