Similar to the SELinux request, I am willing to accept patches for PCRE. I am not a threading or security expert, and I don't want to make things worse (by calling it as an improvement). I understand the basic principles, but I cannot judge the side effects and limitations (CPU/OS/compiler) of those changes. It would be better to discuss proposed patches and land the best solution.
Regards, Zoltan "Giuseppe D'Angelo" <[email protected]> írta: >On Mon, Jan 4, 2016 at 8:58 PM, Zoltán Herczeg <[email protected]> wrote: >> Probably a write barrier would make this perfect, but I am not an expert on >> that, and it requires CPU / OS dependent code. > >Heh, it's not a "probably". > >Although the pointer assignment itself is likely to be atomic on all >the architectures supported by PCRE, this is not guaranteed unless >you're using atomic types (_Atomic in C11), and especially the release >of the memory _pointed to_ is not atomic. Hence you truly need an >atomic pointer and load acquire / store release semantics (in C11: >atomic_store_explicit(jit_data, memory_order_release) in the thread >creating the JIT data, atomic_load_explicit(jit_data, >memory_order_acquire) in the threads performing atches), otherwise >you're triggering undefined behaviour due to a data race. > >(Suppose the thread that performs the jit-study does something like: > >jit_data *j = malloc(...); >j->field1 = 42; >j->field2 = "foo"; >code->jit = j; > >Without a release fence there's nothing preventing a CPU to reorder >these instructions to > >code->jit = j; >j->field2 = "foo"; >j->field1 = 42; > >Hence causing havok on whatever reads code->jit and finds it to be >non-NULL but maybe filled with garbage) > >Cheers, >-- >Giuseppe D'Angelo > -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
