[PATCH v10 2/4] elf: Fix initial-exec TLS access on audit modules (BZ #28096)

[Florian Weimer]

* Adhemerval Zanella via Libc-alpha:

> diff --git a/elf/dl-tls.c b/elf/dl-tls.c
> index 8ba70c9a9d..8ed91ff599 100644
> --- a/elf/dl-tls.c
> +++ b/elf/dl-tls.c
> @@ -520,7 +520,7 @@ _dl_resize_dtv (dtv_t *dtv, size_t max_modid)
>  
>  
>  void *
> -_dl_allocate_tls_init (void *result)
> +_dl_allocate_tls_init (void *result, bool init_tls)
>  {
>    if (result == NULL)
>      /* The memory allocation failed.  */
> @@ -593,7 +593,14 @@ _dl_allocate_tls_init (void *result)
>  	     some platforms use in static programs requires it.  */
>  	  dtv[map->l_tls_modid].pointer.val = dest;
>  
> -	  /* Copy the initialization image and clear the BSS part.  */
> +	  /* Copy the initialization image and clear the BSS part.  For
> +	     audit modules or depedencies with initial-exec TLS, we can not
> +	     set the initial TLS image on default loader initialization
> +	     because it would already be set by the audit setup.  However,
> +	     subsequent thread creation would need to follow the default
> +	     behaviour.   */
> +	  if (__glibc_unlikely (map->l_auditing && !init_tls))
> +	    continue;
>  	  memset (__mempcpy (dest, map->l_tls_initimage,
>  			     map->l_tls_initimage_size), '\0',
>  		  map->l_tls_blocksize - map->l_tls_initimage_size);

I don't understand why the map->l_auditing condition is correct.
Shouldn't it be

  map->l_ns == LM_ID_BASE && !init_tls

?  Everything else has been loaded via dlopen or dlmopen, so TLS
initialization for the main thread has already happened.

Thanks,
Florian