On 27.05.2014 22:33, Ruediger Pluem wrote: > Joe Orton wrote: >> We have a potential race here between threads doing the param >> generation, right? >> >> + static DH *dh = NULL; \ >> + DH *dh_tmp; \ >> ... >> + dh = dh_tmp; \ >> >> though it would not matter who wins the race *if* we could rely on >> pointer assignment being atomic - which is a fairly dubious assumption, > > That was my assumption. If we cannot assume that the pointer assignment is > atomic, > then we have a race problem. > > Would the following patch address your concern?
I would be in favor of fixing the potential race condition in this (or a similar) way... otherwise we would 1) again have to hardcode algorithm-dependent things into one of our structs and 2) "generate" DH parameters at startup even though they might never get be needed (if someone turns off DHE with !kEDH in SSLCipherSuite, none of these DH parameters would ever be used). >> it might be better to do it once at startup to save CPU time anyway? > > I am not that worried about CPU because I guess we fairly quickly get dh set > to a valid value Agree, CPU time is not a concern, get_dh_XXX() is only about populating DH with builtin constants (DH_generate_key happens at connection time, and is fast anyway). Kaspar
