> On 25. Sep 2020, at 15:06, Willy Tarreau <w...@1wt.eu> wrote: > > Till here your analysis is right but: > - the overflow would only be at most the number of extra threads running > init_genrand() concurrently, or more precisely the distance between > the most upfront to the latest thread, so in the worst case nbthread-1 > hence there's no way to write a single location into a totally unrelated > structure without writing the nbthread-2 words that are between the end > of the MT array and the overwritten location ;
I don't think so. We have two threads and steps 1. T1: mti < N 2. T2: mti < N 3. T1: mtii++ 4. T2: mtii++ 5. T1: mt[mti] = (1812433253UL * (mt[mti-1] ^ (mt[mti-1] >> 30)) + mti); 6. T2: mt[mti] = (1812433253UL * (mt[mti-1] ^ (mt[mti-1] >> 30)) + mti); Let assume that mti = N - 1 at steps 1 and 2. At this case mti (aka MT->o) is N + 1 that is overflow of mt array (MT->v). So, when T1 writes something at step 5 it puts a random value to mti (aka MT->i). Here I assume that the sume has dwrod similar that size(long) and MT hasn't got any gaps between v and I. If so at step 6 we have mti with random value and writes to unpredicted place in memory. > - the lua code is not threaded (there's a "big lock" around lua since > stacks cannot easily be protected, though Thierry has some ideas for > this). What does not threaded mean here? I can understand it as all lua function is executed from the only one thread (1), or one call is executed at the same thread but different thread can execute the same lua code for different TCP/HTTP streams at the same time (2). -- wbr, Kirill
signature.asc
Description: Message signed with OpenPGP
