[PATCH v3] elf: Add ELF_DYNAMIC_AFTER_RELOC to rewrite PLT

[Adhemerval Zanella Netto]

On 02/01/24 13:33, Florian Weimer wrote:
> * Adhemerval Zanella Netto:
> 
>>> +  if (GL(dl_x86_feature_control).plt_rewrite == plt_rewrite_enabled)
>>> +    {
>>> +      enum dl_plt_rewrite_control plt_rewrite = plt_rewrite_none;
>>> +
>>> +      /* PLT rewrite is enabled.  Check if mprotect works.  */
>>> +      void *plt = __mmap (NULL, 4096, PROT_READ | PROT_WRITE,
>>> +			  MAP_PRIVATE | MAP_ANONYMOUS,
>>> +			  -1, 0);
>>> +      if (__glibc_unlikely (plt != MAP_FAILED))
>>> +	{
>>> +	  /* Touch the PROT_READ | PROT_WRITE page.  */
>>> +	  *(int32_t *) plt = -1;
>>> +
>>> +	  /* If the updated PROT_READ | PROT_WRITE page can be changed
>>> +	     to PROT_EXEC | PROT_READ, rewrite PLT.  */
>>> +	  if (__mprotect (plt, 4096, PROT_EXEC | PROT_READ) == 0)
>>> +	    /* Use JMPABS on APX processors.  */
>>> +	    plt_rewrite = (CPU_FEATURE_PRESENT_P (__get_cpu_features (),
>>> +						  APX_F)
>>> +			   ? plt_rewrite_jmpabs : plt_rewrite_jmp);
>>> +
>>> +	  __munmap (plt, 4096);
>>> +	}
>>
>> Do we have x86_64 cpu/kernel that does not support setting PROT_EXEC |
>> PROT_READ (afaik only i386 has some restrictions)?  Because this
>> runtime tests is somewhat brittle: mmap might fail or being restricted
>> (for instance due filtering or resource limitation/exaustion).
> 
> I assume you are referring to read-implies-exec here?  Some early x86-64
> CPUs have this property as well.  But even for those, the protection
> flags are tracked by the kernel separately, show up in /proc, etc.
> There's just no CPU enforcement.
> 
> But I think H.J.'s checks are about probing for restrictions imposed by
> Linux security modules.  Some do not allow mapping memory as read/write
> first, and then map it executable.

But does it make sense to add such runtime check when this option is gated
through a tunable? Specially because it might not fully discover whether
kernel does allow it.