RFC: Add a linker warning when creating segments with RWX permissions

Jan Beulich jbeulich@suse.com
Tue Apr 26 13:56:28 GMT 2022


On 26.04.2022 13:31, Nick Clifton via Binutils wrote:
> --- a/bfd/elfcode.h
> +++ b/bfd/elfcode.h
> @@ -388,6 +388,13 @@ elf_swap_phdr_in (bfd *abfd,
>    dst->p_align = H_GET_WORD (abfd, src->p_align);
>  }
>  
> +static inline bool
> +is_memory_resident (const Elf_Internal_Phdr *src)
> +{
> +  /* FIXME: Should we return true for PT_TLS segments ?  */
> +  return src->p_type == PT_LOAD;
> +}

I think for PT_TLS you would want to warn if X is set, no matter
whether R and W are also both set?

> @@ -399,6 +406,27 @@ elf_swap_phdr_out (bfd *abfd,
>    bed = get_elf_backend_data (abfd);
>    p_paddr = bed->want_p_paddr_set_to_zero ? 0 : src->p_paddr;
>  
> +  /* Memory resident segments with non-zero size and RWX permissions are a
> +     security risk, so we generate a warning here if we are creating any.
> +
> +     We suppress the warning if there is only one memory resident segment
> +     however.  This is an an assist for simple programs that do not separate
> +     code and data segments or linker scrips that only define one program
> +     header.  Whilst this is not ideal - even those simple programs will be
> +     vulnerable - the most likely sceanario is that these programs are test
> +     code and not real apps.  */
> +  if (src->p_memsz > 0 && is_memory_resident (src))
> +    {
> +      static unsigned int seen = 0;
> +
> +      if (++ seen > 1)
> +	{
> +	  if ((src->p_flags & (PF_R | PF_W | PF_X)) == (PF_R | PF_W | PF_X))
> +	    _bfd_error_handler (_("warning: %pB has a segment with RWX permissions"),
> +				abfd);
> +	}
> +    }

How would one go about silencing this warning without splitting the
segment? Kernels and alike are likely to have such without this
necessarily being a security risk (eg when this is code/data which
is discarded post-init). I guess that's somewhat similar to
PT_GNU_RELRO, which you also don't check, presumably because at
runtime W will be gone for it.

Jan



More information about the Binutils mailing list