Re: [pcre-dev] PCRE2 and thread safety of jit compilation?

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" <dangelog@???> írta:
>On Mon, Jan 4, 2016 at 8:58 PM, Zoltán Herczeg <hzmester@???> 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
>