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

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

[Nick Clifton]

Hi Guys,

  Following on from the patch to add warnings when the linker creates an
  executable stack, here is another proposal for a patch to add a
  warning when the linker creates a memory resident segment with RWX
  permissions.

  Whilst testing this patch I found that a lot of linker tests were
  failing because they use simple linker scripts that only allocate one
  loadable program header, or combine data and code sections together in
  a single page.  In order to avoid prevent the linker from issuing
  too many warnings therefore, the code only complains if there is more
  than one loadable segment.  Possibly this is too lenient...

  There are still a fair number of linker failures, even with the
  current version of the patch, so I am considering adding an extra
  regexp to the linker warning pruning code in binutils-common.exp.  But
  in the meantime I thought that people might like to see the current
  code and comment on whether or not they thought that this was a good
  idea.

Cheers
  Nick

diff --git a/bfd/elfcode.h b/bfd/elfcode.h
index 4d4cb68164a..385cff1dc13 100644
--- 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;
+}
+
 void
 elf_swap_phdr_out (bfd *abfd,
 		   const Elf_Internal_Phdr *src,
@@ -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);
+	}
+    }
+
   /* note that all elements of dst are *arrays of unsigned char* already...  */
   H_PUT_32 (abfd, src->p_type, dst->p_type);
   H_PUT_WORD (abfd, src->p_offset, dst->p_offset);

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

[Jan Beulich]

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

binutils as policy checker (was: RFC: Add a linker warning when creating segments with RWX permissions)

[Michael Matz]

Hello,

On Tue, 26 Apr 2022, Nick Clifton via Binutils wrote:

>   Following on from the patch to add warnings when the linker creates an
>   executable stack, here is another proposal for a patch to add a
>   warning when the linker creates a memory resident segment with RWX
>   permissions.

Is binutils really the right place to enforce policies?  I'm 
slightly worried about this direction.

I consider all these kinds of checks, which do have some sense, to be 
implementing a certain set of rules that aren't inherent in the design or 
requirements of binary files intended to hold object code and data, i.e. a 
policy.  And for checking adherence to a policy I would expect a policy 
checker tool to be more appropriate than tools designed for creating such 
object files.  Not in the least because policies can sometimes change 
quite quickly (and arbitrarily) and hence need quickly adjustable tooling 
anyway and (even more so) that policies are different for different 
audiences and so encoding one specific policy into a tool looks wrong.

E.g. here I would expect a post-build checker tool to test for RWX 
segments in generated ELF files, like rpmlint and friends, as the distros 
are using already, of course, because that's what the distro makers 
decided to be a policy, not because the binutils authors decided so (I'm 
aware that there's a large overlap in those two sets of people :) ).


Ciao,
Michael.

Re: binutils as policy checker (was: RFC: Add a linker warning when creating segments with RWX permissions)

[Joel Sherrill]

On Tue, Apr 26, 2022 at 10:07 AM Michael Matz via Binutils <
binutils@sourceware.org> wrote:

> Hello,
>
> On Tue, 26 Apr 2022, Nick Clifton via Binutils wrote:
>
> >   Following on from the patch to add warnings when the linker creates an
> >   executable stack, here is another proposal for a patch to add a
> >   warning when the linker creates a memory resident segment with RWX
> >   permissions.
>
> Is binutils really the right place to enforce policies?  I'm
> slightly worried about this direction.
>
> I consider all these kinds of checks, which do have some sense, to be
> implementing a certain set of rules that aren't inherent in the design or
> requirements of binary files intended to hold object code and data, i.e. a
> policy.  And for checking adherence to a policy I would expect a policy
> checker tool to be more appropriate than tools designed for creating such
> object files.  Not in the least because policies can sometimes change
> quite quickly (and arbitrarily) and hence need quickly adjustable tooling
> anyway and (even more so) that policies are different for different
> audiences and so encoding one specific policy into a tool looks wrong.
>
> E.g. here I would expect a post-build checker tool to test for RWX
> segments in generated ELF files, like rpmlint and friends, as the distros
> are using already, of course, because that's what the distro makers
> decided to be a policy, not because the binutils authors decided so (I'm
> aware that there's a large overlap in those two sets of people :) ).
>

RTEMS can run paravirtualized in an ARINC 653 RTOS for avionics
applications.
That RTOS has a utility to check executables like you suggest.

I also found this Ubuntu man page online which appears to be along
the lines you are suggesting:

http://manpages.ubuntu.com/manpages/trusty/man1/hardening-check.1.html

Those look like generic checks which might apply to any gcc/binutils
target environment but, as you state, it is the distribution that sets the
policy set.

Maybe something that can make the checks but be tailorable. At least
the source for the checks would be shared then and a wrapper script
could enforce the policy.

Just thinking out loud.

--joel


>
>
> Ciao,
> Michael.
>

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

[Nick Clifton]

Hi Jan,

>> +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?

Agreed.


> How would one go about silencing this warning without splitting the
> segment? 

Hmmm - a good point.  There needs to be a new option to silence the warning.
Either that or the --no-warn-execstack option could be extended to silence
this warning.

Cheers
   Nick

Re: binutils as policy checker (was: RFC: Add a linker warning when creating segments with RWX permissions)

[Nick Clifton]

Hi Michael,

>>    Following on from the patch to add warnings when the linker creates an
>>    executable stack, here is another proposal for a patch to add a
>>    warning when the linker creates a memory resident segment with RWX
>>    permissions.
> 
> Is binutils really the right place to enforce policies?

Enforce - no.  But I do think that the binutils - or more specifically
the linker - is a good place to detect this sort of problem and provide
feedback to the user.


> I consider all these kinds of checks, which do have some sense, to be
> implementing a certain set of rules that aren't inherent in the design or
> requirements of binary files intended to hold object code and data, i.e. a
> policy.  

That is fair.  The original intent for these warnings was to alert users
to potential security risks that might otherwise be hidden from them.  But
that assumes that the user cares about such risks and wants/needs to be
informed.

Perhaps what is needed here is the idea suggested by Sam James - a configure
time option to enable or disable these checks and warnings.  An option that
could default to off for now, but which we could change to default to on in
a later release.


> And for checking adherence to a policy I would expect a policy
> checker tool to be more appropriate than tools designed for creating such
> object files.

As an aside the annobin project/package is exactly this - a checker tool
for enforcing a specific security policy when building binaries.

Cheers
   Nick

Re: binutils as policy checker (was: RFC: Add a linker warning when creating segments with RWX permissions)

[Nick Clifton]

[-- Attachment #1: Type: text/plain, Size: 1488 bytes --]

Hi Guys,

   OK, attached is v2 of my proposed patch.  The main features of this
   new version are:

     * There are now configure options which can turn off the generation
       of linker warnings about the creation of executable segments and
       the creation of executable stacks.  By default however not using
       these configure options will result in the creation of a linker
       with all of the warnings enabled.

     * There is new linker command line option: --no-warn-rwx-segments
       which disables the warnings about executable segments.

     * There are tests for the new features, plus extra regexps in the
       testsuite's pruning proc to remove the warnings from the linker's
       output for normal tests.

     * The creation of a TLS segment with eXecute permission will trigger
       a warning, regardless of whether it has the read and/or write
       permissions set.

     * There is a new configure time option which will disable the
       creation of an executable stack simply because an input file is
       missing a .note-GNU-stack section (for those architectures where
       such a creation is the normal behaviour).  This option is not
       enabled by default however.  At least not yet.

   I think that this represents the best compromise between helping to
   promote secure builds whilst also allowing toolchain creators and
   program builders the option to disable the features if they wish.

   Any comments ?

Cheers
   Nick

[-- Attachment #2: ld-rwx-warn.patch --]
[-- Type: text/x-patch, Size: 17789 bytes --]

diff --git a/bfd/elf.c b/bfd/elf.c
index 37c53cfdf32..dda47da9d0e 100644
--- a/bfd/elf.c
+++ b/bfd/elf.c
@@ -6461,6 +6461,29 @@ assign_file_positions_except_relocs (bfd *abfd,
   alloc = i_ehdrp->e_phnum;
   if (alloc != 0)
     {
+      if (link_info != NULL && ! link_info->no_warn_rwx_segments)
+	{
+	  /* 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.  */
+	  unsigned int i;
+
+	  for (i = 0; i < alloc; i++)
+	    {
+	      const Elf_Internal_Phdr * phdr = tdata->phdr + i;
+
+	      if (phdr->p_memsz == 0)
+		continue;
+
+	      if (phdr->p_type == PT_TLS && (phdr->p_flags & PF_X))
+		_bfd_error_handler (_("warning: %pB has a TLS segment with execute permission"),
+				    abfd);
+	      else if (phdr->p_type == PT_LOAD
+		       && (phdr->p_flags & (PF_R | PF_W | PF_X)) == (PF_R | PF_W | PF_X))
+		_bfd_error_handler (_("warning: %pB has a LOAD segment with RWX permissions"),
+				    abfd);
+	    }
+	}
+      
       if (bfd_seek (abfd, i_ehdrp->e_phoff, SEEK_SET) != 0
 	  || bed->s->write_out_phdrs (abfd, tdata->phdr, alloc) != 0)
 	return false;
diff --git a/bfd/elflink.c b/bfd/elflink.c
index b54ee517c75..4d6fe663f68 100644
--- a/bfd/elflink.c
+++ b/bfd/elflink.c
@@ -7168,7 +7168,7 @@ warning: enabling an executable stack because of -z execstack command line optio
 		  break;
 		}
 	    }
-	  else if (bed->default_execstack)
+	  else if (bed->default_execstack && info->default_execstack)
 	    {
 	      exec = PF_X;
 	      emptyobj = inputobj;
diff --git a/binutils/testsuite/lib/binutils-common.exp b/binutils/testsuite/lib/binutils-common.exp
index a76a310c199..ccc33a827b4 100644
--- a/binutils/testsuite/lib/binutils-common.exp
+++ b/binutils/testsuite/lib/binutils-common.exp
@@ -639,6 +639,8 @@ proc prune_warnings_extra { text } {
     regsub -all "(^|\n)(\[^\n\]*: Warning: Gap in build notes detected from\[^\n\]*\n?)+" $text "\\1" text
     regsub -all "(^|\n)(\[^\n\]*: warning:\[^\n\]*missing \\.note\\.GNU-stack section\[^\n\]*\n?)+" $text "\\1" text
     regsub -all "(^|\n)(\[^\n\]*: NOTE: This behaviour is deprecated\[^\n\]*\n?)+" $text "\\1" text
+    regsub -all "(^|\n)(\[^\n\]*: warning:\[^\n\]*has a LOAD segment with RWX permissions\[^\n\]*\n?)+" $text "\\1" text
+    regsub -all "(^|\n)(\[^\n\]*: warning:\[^\n\]*has a TLS segment with execute permission\[^\n\]*\n?)+" $text "\\1" text
     return $text
 }
 
diff --git a/include/bfdlink.h b/include/bfdlink.h
index b16f3f44ca5..88cc8e26183 100644
--- a/include/bfdlink.h
+++ b/include/bfdlink.h
@@ -489,10 +489,25 @@ struct bfd_link_info
      flags.  */
   unsigned int noexecstack: 1;
 
-  /* Tri-state variable: 0 => not set by user; 1 => set, warnings
-     enabled; 2 => warnings disabled; 3 => unused.  */
+  /* Tri-state variable:
+     0 => warn if the linker is creating an executable stack, but
+     execstack (above) is 0.
+     1 => warn if the linker is creating an executable stack; ignores
+     the value of execstack.
+     2 => do not warn.
+     3 => not used.  */
   unsigned int warn_execstack: 2;
 
+  /* TRUE if warnings should not be generated for TLS segments with eXecute
+     permission or LOAD segments with RWX permissions.  */
+  unsigned int no_warn_rwx_segments: 1;
+
+  /* TRUE if the stack can be made executable because of the absence of a
+     .note.GNU-stack section in an input file.  Note - even if this field
+     is set, some targets may choose to ignore the setting and not create
+     an executable stack.  */
+  unsigned int default_execstack : 1;
+  
   /* TRUE if we want to produced optimized output files.  This might
      need much more time and therefore must be explicitly selected.  */
   unsigned int optimize: 1;
diff --git a/ld/NEWS b/ld/NEWS
index b84553109d2..514d1d9f207 100644
--- a/ld/NEWS
+++ b/ld/NEWS
@@ -1,6 +1,6 @@
 -*- text -*-
 
-* The linker will now generate a warning message if the stack is made
+* The ELF linker will now generate a warning message if the stack is made
   executable.  By default this warning is not issued if the user has
   specifically requested an executable stack via the "-z execstack"
   command line option, but the warning can be forced via the new
@@ -8,6 +8,28 @@
   an executable stack can be suppressed via the "--no-warn-execstack"
   option.
 
+  In addition the ELF linker will also warn if it creates a memory resident
+  segment with all three of the Read, Write and eXecute permissions set, or
+  if it creates a thread local data segment with the eXecute permission set.
+  These warnings can be disabled via --no-warn-rwx-segments option and
+  re-enabled via the --warn-rwx-segments option.
+
+  New configure options can also control these new features:
+  
+  --enable-warn-execstack=no
+     will disable the warnings about creating an executable stack.
+     
+  --enable-warn-execstack=yes
+     will make --warn-execstack enabled by default.
+     
+  --enable-warn-rwx-segments=no
+     will make --no-warn-rwx-segments enabled by default.
+     
+  --enable-defaul-execstack=no
+     will stop the creation of an executable stack simply because an input file
+     is missing a .note.GNU-stack section, even on architectures where this
+     ehaviour is the default.
+
 * TYPE=<type> is now supported in an output section description to set the
   section type value.
 
diff --git a/ld/configure.ac b/ld/configure.ac
index 7f4cff079b7..0b29e810dde 100644
--- a/ld/configure.ac
+++ b/ld/configure.ac
@@ -203,6 +203,35 @@ AC_ARG_ENABLE(separate-code,
   no) ac_default_ld_z_separate_code=0 ;;
 esac])
 
+
+ac_default_ld_warn_execstack=unset
+AC_ARG_ENABLE(warn-execstack,
+	      AS_HELP_STRING([--enable-warn-execstack],
+	      [enable warnings when creating an executable stack]),
+[case "${enableval}" in
+  yes) ac_default_ld_warn_execstack=1 ;;
+  no)  ac_default_ld_warn_execstack=-1 ;;
+esac])
+
+ac_default_ld_warn_rwx_segments=unset
+AC_ARG_ENABLE(warn-rwx-segments,
+	      AS_HELP_STRING([--enable-warn-rwx-segments],
+	      [enable warnings when creating segements with RWX permissions]),
+[case "${enableval}" in
+  yes) ac_default_ld_warn_rwx_segments=1 ;;
+  no)  ac_default_ld_warn_rwx_segments=0 ;;
+esac])
+
+ac_default_ld_default_execstack=unset
+AC_ARG_ENABLE(default-execstack,
+	      AS_HELP_STRING([--enable-default-execstack],
+	      [create an executable stack if an input file is missing a .note.GNU-stack section]),
+[case "${enableval}" in
+  yes) ac_default_ld_default_execstack=1 ;;
+  no)  ac_default_ld_default_execstack=0 ;;
+esac])
+
+
 # Decide if --error-handling-script should be supported.
 ac_support_error_handling_script=unset
 AC_ARG_ENABLE(error-handling-script,
@@ -501,6 +530,29 @@ AC_DEFINE_UNQUOTED(DEFAULT_LD_Z_SEPARATE_CODE,
   $ac_default_ld_z_separate_code,
   [Define to 1 if you want to enable -z separate-code in ELF linker by default.])
 
+
+if test "${ac_default_ld_warn_execstack}" = unset; then
+  ac_default_ld_warn_execstack=0
+fi
+AC_DEFINE_UNQUOTED(DEFAULT_LD_WARN_EXECSTACK,
+  $ac_default_ld_warn_execstack,
+  [Define to 1 if you want to enable --warn-execstack in ELF linker by default.])
+
+if test "${ac_default_ld_warn_rwx_segments}" = unset; then
+  ac_default_ld_warn_rwx_segments=1
+fi
+AC_DEFINE_UNQUOTED(DEFAULT_LD_WARN_RWX_SEGMENTS,
+  $ac_default_ld_warn_rwx_segments,
+  [Define to 0 if you want to disable --warn-rwx-segments in ELF linker by default.])
+
+if test "${ac_default_ld_default_execstack}" = unset; then
+  ac_default_ld_default_execstack=1
+fi
+AC_DEFINE_UNQUOTED(DEFAULT_LD_EXECSTACK,
+  $ac_default_ld_default_execstack,
+  [Define to 0 if you want to disable the generation of an executable stack when a .note-GNU-stack section is missing.])
+
+
 if test "${ac_support_error_handling_script}" = unset; then
   ac_support_error_handling_script=1
 fi
diff --git a/ld/emultempl/elf.em b/ld/emultempl/elf.em
index 7ae6f6d50e1..c027559908c 100644
--- a/ld/emultempl/elf.em
+++ b/ld/emultempl/elf.em
@@ -92,6 +92,9 @@ EOF
 fi
 fragment <<EOF
   link_info.separate_code = DEFAULT_LD_Z_SEPARATE_CODE;
+  link_info.warn_execstack = DEFAULT_LD_WARN_EXECSTACK;
+  link_info.no_warn_rwx_segments = ! DEFAULT_LD_WARN_RWX_SEGMENTS;
+  link_info.default_execstack = DEFAULT_LD_EXECSTACK;
 }
 
 EOF
diff --git a/ld/ld.texi b/ld/ld.texi
index 6ac5344ebf4..8cad8478140 100644
--- a/ld/ld.texi
+++ b/ld/ld.texi
@@ -2701,6 +2701,22 @@ option causes a warning to be issued whenever this case occurs.
 Only warn once for each undefined symbol, rather than once per module
 which refers to it.
 
+@kindex --warn-rwx-segments
+@cindex warnings, on writeable and exectuable segments
+@cindex executable segments, warnings on
+@item --warn-rwx-segments
+@itemx --no-warn-rwx-segments
+Warn if the linker creates a loadable, non-zero sized segment that has
+all three of the read, write and execute permission flags set.  Such a
+segment represents a potential security vulnerability.  In addition
+warnings will be generated if a thread local storage segment is
+created with the execute permission flag set, regardless of whether or
+not it has the read and/or write flags set.
+
+These warnings are enabled by default.  They can be disabled via the
+@option{--no-warn-rwx-segments} option and re-enabled via the
+@option{--warn-rwx-segments} option.
+
 @kindex --warn-section-align
 @cindex warnings, on section alignment
 @cindex section alignment, warnings on
diff --git a/ld/ldlex.h b/ld/ldlex.h
index 1d42dc8672e..57ade1f754b 100644
--- a/ld/ldlex.h
+++ b/ld/ldlex.h
@@ -166,10 +166,13 @@ enum option_values
   OPTION_CTF_SHARE_TYPES,
   OPTION_WARN_EXECSTACK,
   OPTION_NO_WARN_EXECSTACK,
+  OPTION_WARN_RWX_SEGMENTS,
+  OPTION_NO_WARN_RWX_SEGMENTS,
 };
 
 /* The initial parser states.  */
-typedef enum input_enum {
+typedef enum input_enum
+{
   input_selected,		/* We've set the initial state.  */
   input_script,
   input_mri_script,
diff --git a/ld/lexsup.c b/ld/lexsup.c
index 2929fecb604..78190472907 100644
--- a/ld/lexsup.c
+++ b/ld/lexsup.c
@@ -540,6 +540,10 @@ static const struct ld_option ld_options[] =
     '\0', NULL, N_("Warn when creating an executable stack"), TWO_DASHES },
   { {"no-warn-execstack", no_argument, NULL, OPTION_NO_WARN_EXECSTACK},
     '\0', NULL, N_("Do not warn when creating an executable stack"), TWO_DASHES },
+  { {"warn-rwx-segments", no_argument, NULL, OPTION_WARN_RWX_SEGMENTS},
+    '\0', NULL, N_("Warn when creating executable segments"), TWO_DASHES },
+  { {"no-warn-rwx-segments", no_argument, NULL, OPTION_NO_WARN_RWX_SEGMENTS},
+    '\0', NULL, N_("Do not warn when creating executable segments"), TWO_DASHES },
   { {"warn-multiple-gp", no_argument, NULL, OPTION_WARN_MULTIPLE_GP},
     '\0', NULL, N_("Warn if the multiple GP values are used"), TWO_DASHES },
   { {"warn-once", no_argument, NULL, OPTION_WARN_ONCE},
@@ -925,6 +929,12 @@ parse_args (unsigned argc, char **argv)
 	case OPTION_NO_WARN_EXECSTACK:
 	  link_info.warn_execstack = 2;
 	  break;
+	case OPTION_WARN_RWX_SEGMENTS:
+	  link_info.no_warn_rwx_segments = 0;
+	  break;
+	case OPTION_NO_WARN_RWX_SEGMENTS:
+	  link_info.no_warn_rwx_segments = 1;
+	  break;
 	case 'e':
 	  lang_add_entry (optarg, true);
 	  break;
@@ -2159,10 +2169,31 @@ elf_static_list_options (FILE *file)
   -z execstack                Mark executable as requiring executable stack\n"));
   fprintf (file, _("\
   -z noexecstack              Mark executable as not requiring executable stack\n"));
+#if DEFAULT_LD_WARN_EXECSTACK > 0
+  fprintf (file, _("\
+  --warn-execstack            Generate a warning if the stack is executable (default)\n"));
+#else
   fprintf (file, _("\
   --warn-execstack            Generate a warning if the stack is executable\n"));
+#endif
+#if DEFAULT_LD_WARN_EXECSTACK < 0
+  fprintf (file, _("\
+  --no-warn-execstack         Do not generate a warning if the stack is executable (default)\n"));
+#else
   fprintf (file, _("\
   --no-warn-execstack         Do not generate a warning if the stack is executable\n"));
+#endif
+#if DEFAULT_LD_WARN_RWX_SEGMENTS
+  fprintf (file, _("\
+  --warn-rwx-segments         Generate a warning if a LOAD segment has RWX permissions (default)\n"));
+  fprintf (file, _("\
+  --no-warn-rwx-segments      Do not generate a warning if a LOAD segments has RWX permissions\n"));
+#else
+  fprintf (file, _("\
+  --warn-rwx-segments         Generate a warning if a LOAD segment has RWX permissions\n"));
+  fprintf (file, _("\
+  --no-warn-rwx-segments      Do not generate a warning if a LOAD segments has RWX permissions (default)\n"));
+#endif
   fprintf (file, _("\
   -z unique-symbol            Avoid duplicated local symbol names\n"));
   fprintf (file, _("\
diff --git a/ld/testsuite/ld-elf/changelma.d b/ld/testsuite/ld-elf/changelma.d
index 858a8db37ae..567e72d3301 100644
--- a/ld/testsuite/ld-elf/changelma.d
+++ b/ld/testsuite/ld-elf/changelma.d
@@ -1,5 +1,5 @@
 #name: changelma (pr20659)
-#ld: -T changelma.lnk
+#ld: -T changelma.lnk --no-warn-rwx-segments
 #objcopy_linked_file: --change-section-lma .dynamic+0x80000000
 #readelf: -l --wide
 #xfail: rx-*-*
diff --git a/ld/testsuite/ld-elf/elf.exp b/ld/testsuite/ld-elf/elf.exp
index d56154011b3..77e8ca381fb 100644
--- a/ld/testsuite/ld-elf/elf.exp
+++ b/ld/testsuite/ld-elf/elf.exp
@@ -226,7 +226,18 @@ if {   [istarget *-*-*linux*]
 	    "" \
 	    {pr23900-1.s} \
 	    [list [list "readelf" {-Wl} $pr23900_1_exp]] \
-	    "pr23900-1.exe"] \
+	     "pr23900-1.exe"] \
+	  ]
+
+    # Test the linker's generation of execstack and executable segment warnings.
+    # Since these are normally pruned from the linker's output we temporarily
+    # disable tha action here.
+    rename prune_warnings_extra old_prune_warnings_extra
+    proc prune_warnings_extra { text } {
+	return $text
+    }
+    
+    run_ld_link_tests [list \
 	[list "PR ld/29072 (warn about an executable .note.GNU-stack)" \
 	    "-e 0" \
 	    "" \
@@ -248,23 +259,39 @@ if {   [istarget *-*-*linux*]
 	    {pr29072-a.s} \
 	    {} \
 	    "pr29072-d.exe"] \
-	]
+	[list "Ensure that a warning issued when creating a segment with RWX permissions" \
+	    "-e 0 -Tnobits-1.t --warn-rwx-segments" \
+	    "" \
+	    "" \
+	    {nobits-1.s} \
+	     {{ld rwx-segments-1.l}} \
+	    "rwx-segments-1.exe"] \
+	[list "Ensure that a warning issued when creating a TLS segment with execute permission" \
+	    "-e 0 -T rwx-segments-2.t --warn-rwx-segments" \
+	    "" \
+	    "" \
+	    {size-2.s} \
+	     {{ld rwx-segments-2.l}} \
+	    "rwx-segments-2.exe"] \
+	[list "Ensure that the warning can be suppressed" \
+	    "-e 0 -Tnobits-1.t --no-warn-rwx-segments" \
+	    "" \
+	    "" \
+	    {nobits-1.s} \
+	     {} \
+	    "rwx-segments-3.exe"] \
+	  ]
+
     if { [target_defaults_to_execstack] } {
-	rename prune_warnings_extra old_prune_warnings_extra
-	proc prune_warnings_extra { text } {
-	    return $text
-	}
 	run_ld_link_tests [list \
 	   [list "PR ld/29072 (warn about absent .note.GNU-stack)" \
-	    "-e 0 -z stack-size=0x123400" \
+	    "-e 0 -z stack-size=0x123400  --warn-execstack" \
 	    "" \
 	    "" \
 	    {pr29072-b.s} \
 	    {{ld pr29072.b.warn}} \
 	    "pr29072-b.exe"] \
 	]
-	rename prune_warnings_extra ""
-	rename old_prune_warnings_extra prune_warnings_extra
     } else {
 	run_ld_link_tests [list \
 	   [list "PR ld/29072 (ignore absent .note.GNU-stack)" \
@@ -276,6 +303,10 @@ if {   [istarget *-*-*linux*]
 	    "pr29072-b.exe"] \
 	]
     }
+
+    # Restore the normal pruning behaviour.
+    rename prune_warnings_extra ""
+    rename old_prune_warnings_extra prune_warnings_extra
 }
 
 if [check_gc_sections_available] {
diff --git a/ld/testsuite/ld-elf/flags1.d b/ld/testsuite/ld-elf/flags1.d
index 6cd8b3f3832..d9034e25dc7 100644
--- a/ld/testsuite/ld-elf/flags1.d
+++ b/ld/testsuite/ld-elf/flags1.d
@@ -1,5 +1,5 @@
 #name: --set-section-flags test 1 (sections)
-#ld: -Tflags1.ld
+#ld: -Tflags1.ld --no-warn-rwx-segments
 #objcopy_linked_file: --set-section-flags .post_text_reserve=contents,alloc,load,readonly,code
 #readelf: -S --wide
 
diff --git a/ld/testsuite/ld-elf/maxpage5.d b/ld/testsuite/ld-elf/maxpage5.d
index 9d9b57a853a..843a976111a 100644
--- a/ld/testsuite/ld-elf/maxpage5.d
+++ b/ld/testsuite/ld-elf/maxpage5.d
@@ -1,6 +1,6 @@
 #source: maxpage5.s
 #as: --32
-#ld: -z max-page-size=0x200000 -T maxpage5.t
+#ld: -z max-page-size=0x200000 -T maxpage5.t --no-warn-rwx-segments
 #objcopy_linked_file: -R .foo
 #readelf: -l --wide
 #target: x86_64-*-linux* i?86-*-linux-gnu i?86-*-gnu*
diff --git a/ld/testsuite/ld-elf/note-2.d b/ld/testsuite/ld-elf/note-2.d
index aff32406de2..ed81703dc2d 100644
--- a/ld/testsuite/ld-elf/note-2.d
+++ b/ld/testsuite/ld-elf/note-2.d
@@ -1,4 +1,4 @@
-#ld: -Tnote-2.t
+#ld: -Tnote-2.t --no-warn-rwx-segments
 #objcopy_linked_file: -R .foo 
 #readelf: -l --wide
 
--- /dev/null	2022-04-27 08:15:27.358010516 +0100
+++ current/ld/testsuite/ld-elf/rwx-segments-1.l	2022-04-27 10:17:48.254919300 +0100
@@ -0,0 +1 @@
+.*warning: .* has a LOAD segment with RWX permissions
--- /dev/null	2022-04-27 08:15:27.358010516 +0100
+++ current/ld/testsuite/ld-elf/rwx-segments-2.l	2022-04-27 10:20:05.996410468 +0100
@@ -0,0 +1 @@
+.*: warning: .* has a TLS segment with execute permission
--- /dev/null	2022-04-27 08:15:27.358010516 +0100
+++ current/ld/testsuite/ld-elf/rwx-segments-2.t	2022-04-27 09:58:04.661284493 +0100
@@ -0,0 +1,20 @@
+PHDRS
+{
+  header PT_PHDR PHDRS ;
+	 
+  image PT_LOAD FLAGS (5) PHDRS;
+  tls   PT_TLS  FLAGS (7);
+  
+}
+SECTIONS
+{
+  .text 0x100 : { *(.text) } :image
+  .tdata : { *(.tdata) } :image :tls
+  .tbss : { *(.tbss) } :image : tls
+  .map : {
+    LONG (SIZEOF (.text))
+    LONG (SIZEOF (.tdata))
+    LONG (SIZEOF (.tbss))
+  } :image
+  /DISCARD/ : { *(*) }
+}

Re: binutils as policy checker (was: RFC: Add a linker warning when creating segments with RWX permissions)

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 1755 bytes --]



> On 28 Apr 2022, at 10:46, Nick Clifton via Binutils <binutils@sourceware.org> wrote:
> 
> Hi Guys,
> 
>  OK, attached is v2 of my proposed patch.  The main features of this
>  new version are:
> 
>    * There are now configure options which can turn off the generation
>      of linker warnings about the creation of executable segments and
>      the creation of executable stacks.  By default however not using
>      these configure options will result in the creation of a linker
>      with all of the warnings enabled.
> 
>    * There is new linker command line option: --no-warn-rwx-segments
>      which disables the warnings about executable segments.
> 
>    * There are tests for the new features, plus extra regexps in the
>      testsuite's pruning proc to remove the warnings from the linker's
>      output for normal tests.
> 
>    * The creation of a TLS segment with eXecute permission will trigger
>      a warning, regardless of whether it has the read and/or write
>      permissions set.
> 
>    * There is a new configure time option which will disable the
>      creation of an executable stack simply because an input file is
>      missing a .note-GNU-stack section (for those architectures where
>      such a creation is the normal behaviour).  This option is not
>      enabled by default however.  At least not yet.
> 
>  I think that this represents the best compromise between helping to
>  promote secure builds whilst also allowing toolchain creators and
>  program builders the option to disable the features if they wish.
> 
>  Any comments ?

WFM and thanks for taking my comments into account -- much appreciated!

> 
> Cheers
>  Nick<ld-rwx-warn.patch>

best,
sam


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: binutils as policy checker (was: RFC: Add a linker warning when creating segments with RWX permissions)

[Michael Matz]

Hey,

On Thu, 28 Apr 2022, Nick Clifton via Binutils wrote:

>     * There are now configure options which can turn off the generation
>       of linker warnings about the creation of executable segments and
>       the creation of executable stacks.  By default however not using
>       these configure options will result in the creation of a linker
>       with all of the warnings enabled.
> 
>     * There is new linker command line option: --no-warn-rwx-segments
>       which disables the warnings about executable segments.
> 
>     * There are tests for the new features, plus extra regexps in the
>       testsuite's pruning proc to remove the warnings from the linker's
>       output for normal tests.
> 
>     * The creation of a TLS segment with eXecute permission will trigger
>       a warning, regardless of whether it has the read and/or write
>       permissions set.
> 
>     * There is a new configure time option which will disable the
>       creation of an executable stack simply because an input file is
>       missing a .note-GNU-stack section (for those architectures where
>       such a creation is the normal behaviour).  This option is not
>       enabled by default however.  At least not yet.
> 
>   I think that this represents the best compromise between helping to
>   promote secure builds whilst also allowing toolchain creators and
>   program builders the option to disable the features if they wish.
> 
>   Any comments ?

Works for me.


Ciao,
Michael.

Re: binutils as policy checker (was: RFC: Add a linker warning when creating segments with RWX permissions)

[Matthias Klose]

On 28.04.22 11:46, Nick Clifton via Binutils wrote:
> Hi Guys,
> 
>    OK, attached is v2 of my proposed patch.  The main features of this
>    new version are:
> 
>      * There are now configure options which can turn off the generation
>        of linker warnings about the creation of executable segments and
>        the creation of executable stacks.  By default however not using
>        these configure options will result in the creation of a linker
>        with all of the warnings enabled.
> 
>      * There is new linker command line option: --no-warn-rwx-segments
>        which disables the warnings about executable segments.
> 
>      * There are tests for the new features, plus extra regexps in the
>        testsuite's pruning proc to remove the warnings from the linker's
>        output for normal tests.
> 
>      * The creation of a TLS segment with eXecute permission will trigger
>        a warning, regardless of whether it has the read and/or write
>        permissions set.
> 
>      * There is a new configure time option which will disable the
>        creation of an executable stack simply because an input file is
>        missing a .note-GNU-stack section (for those architectures where
>        such a creation is the normal behaviour).  This option is not
>        enabled by default however.  At least not yet.
> 
>    I think that this represents the best compromise between helping to
>    promote secure builds whilst also allowing toolchain creators and
>    program builders the option to disable the features if they wish.
> 
>    Any comments ?

this commit contains a ld/aclocal.m4 generated with automake 1.16.  Please 
re-create that file with automake 1.15.1. And maybe re-create the Makefile.in 
also with the correct automake version.

Thanks, Matthias

Re: binutils as policy checker (was: RFC: Add a linker warning when creating segments with RWX permissions)

[H.J. Lu]

[-- Attachment #1: Type: text/plain, Size: 1981 bytes --]

On Tue, May 3, 2022 at 12:35 PM Matthias Klose <doko@ubuntu.com> wrote:
>
> On 28.04.22 11:46, Nick Clifton via Binutils wrote:
> > Hi Guys,
> >
> >    OK, attached is v2 of my proposed patch.  The main features of this
> >    new version are:
> >
> >      * There are now configure options which can turn off the generation
> >        of linker warnings about the creation of executable segments and
> >        the creation of executable stacks.  By default however not using
> >        these configure options will result in the creation of a linker
> >        with all of the warnings enabled.
> >
> >      * There is new linker command line option: --no-warn-rwx-segments
> >        which disables the warnings about executable segments.
> >
> >      * There are tests for the new features, plus extra regexps in the
> >        testsuite's pruning proc to remove the warnings from the linker's
> >        output for normal tests.
> >
> >      * The creation of a TLS segment with eXecute permission will trigger
> >        a warning, regardless of whether it has the read and/or write
> >        permissions set.
> >
> >      * There is a new configure time option which will disable the
> >        creation of an executable stack simply because an input file is
> >        missing a .note-GNU-stack section (for those architectures where
> >        such a creation is the normal behaviour).  This option is not
> >        enabled by default however.  At least not yet.
> >
> >    I think that this represents the best compromise between helping to
> >    promote secure builds whilst also allowing toolchain creators and
> >    program builders the option to disable the features if they wish.
> >
> >    Any comments ?
>
> this commit contains a ld/aclocal.m4 generated with automake 1.16.  Please
> re-create that file with automake 1.15.1. And maybe re-create the Makefile.in
> also with the correct automake version.
>
> Thanks, Matthias

I am checking in this.

-- 
H.J.

[-- Attachment #2: 0001-ld-Regenerate-aclocal.m4-with-automake-1.15.1.patch --]
[-- Type: text/x-patch, Size: 16758 bytes --]

From 3c688b9e388db62a30ca9bd05ae32caf507b2a90 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Tue, 3 May 2022 12:56:05 -0700
Subject: [PATCH] ld: Regenerate aclocal.m4 with automake 1.15.1

	* aclocal.m4: Regenerate with automake 1.15.1.
---
 ld/aclocal.m4 | 193 +++++++++++++++++++++++++++-----------------------
 1 file changed, 104 insertions(+), 89 deletions(-)

diff --git a/ld/aclocal.m4 b/ld/aclocal.m4
index 314969c6dd8..631ead7b2ca 100644
--- a/ld/aclocal.m4
+++ b/ld/aclocal.m4
@@ -1,6 +1,6 @@
-# generated automatically by aclocal 1.16.2 -*- Autoconf -*-
+# generated automatically by aclocal 1.15.1 -*- Autoconf -*-
 
-# Copyright (C) 1996-2020 Free Software Foundation, Inc.
+# Copyright (C) 1996-2017 Free Software Foundation, Inc.
 
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
@@ -20,7 +20,7 @@ You have another version of autoconf.  It may work, but is not guaranteed to.
 If you have problems, you may need to regenerate the build system entirely.
 To do so, use the procedure documented by the package, typically 'autoreconf'.])])
 
-# Copyright (C) 2002-2020 Free Software Foundation, Inc.
+# Copyright (C) 2002-2017 Free Software Foundation, Inc.
 #
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
@@ -32,10 +32,10 @@ To do so, use the procedure documented by the package, typically 'autoreconf'.])
 # generated from the m4 files accompanying Automake X.Y.
 # (This private macro should not be called outside this file.)
 AC_DEFUN([AM_AUTOMAKE_VERSION],
-[am__api_version='1.16'
+[am__api_version='1.15'
 dnl Some users find AM_AUTOMAKE_VERSION and mistake it for a way to
 dnl require some minimum version.  Point them to the right macro.
-m4_if([$1], [1.16.2], [],
+m4_if([$1], [1.15.1], [],
       [AC_FATAL([Do not call $0, use AM_INIT_AUTOMAKE([$1]).])])dnl
 ])
 
@@ -51,14 +51,14 @@ m4_define([_AM_AUTOCONF_VERSION], [])
 # Call AM_AUTOMAKE_VERSION and AM_AUTOMAKE_VERSION so they can be traced.
 # This function is AC_REQUIREd by AM_INIT_AUTOMAKE.
 AC_DEFUN([AM_SET_CURRENT_AUTOMAKE_VERSION],
-[AM_AUTOMAKE_VERSION([1.16.2])dnl
+[AM_AUTOMAKE_VERSION([1.15.1])dnl
 m4_ifndef([AC_AUTOCONF_VERSION],
   [m4_copy([m4_PACKAGE_VERSION], [AC_AUTOCONF_VERSION])])dnl
 _AM_AUTOCONF_VERSION(m4_defn([AC_AUTOCONF_VERSION]))])
 
 # AM_AUX_DIR_EXPAND                                         -*- Autoconf -*-
 
-# Copyright (C) 2001-2020 Free Software Foundation, Inc.
+# Copyright (C) 2001-2017 Free Software Foundation, Inc.
 #
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
@@ -110,7 +110,7 @@ am_aux_dir=`cd "$ac_aux_dir" && pwd`
 
 # AM_CONDITIONAL                                            -*- Autoconf -*-
 
-# Copyright (C) 1997-2020 Free Software Foundation, Inc.
+# Copyright (C) 1997-2017 Free Software Foundation, Inc.
 #
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
@@ -141,7 +141,7 @@ AC_CONFIG_COMMANDS_PRE(
 Usually this means the macro was only invoked conditionally.]])
 fi])])
 
-# Copyright (C) 1999-2020 Free Software Foundation, Inc.
+# Copyright (C) 1999-2017 Free Software Foundation, Inc.
 #
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
@@ -332,12 +332,13 @@ _AM_SUBST_NOTMAKE([am__nodep])dnl
 
 # Generate code to set up dependency tracking.              -*- Autoconf -*-
 
-# Copyright (C) 1999-2020 Free Software Foundation, Inc.
+# Copyright (C) 1999-2017 Free Software Foundation, Inc.
 #
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
 # with or without modifications, as long as this notice is preserved.
 
+
 # _AM_OUTPUT_DEPENDENCY_COMMANDS
 # ------------------------------
 AC_DEFUN([_AM_OUTPUT_DEPENDENCY_COMMANDS],
@@ -345,43 +346,49 @@ AC_DEFUN([_AM_OUTPUT_DEPENDENCY_COMMANDS],
   # Older Autoconf quotes --file arguments for eval, but not when files
   # are listed without --file.  Let's play safe and only enable the eval
   # if we detect the quoting.
-  # TODO: see whether this extra hack can be removed once we start
-  # requiring Autoconf 2.70 or later.
-  AS_CASE([$CONFIG_FILES],
-          [*\'*], [eval set x "$CONFIG_FILES"],
-          [*], [set x $CONFIG_FILES])
+  case $CONFIG_FILES in
+  *\'*) eval set x "$CONFIG_FILES" ;;
+  *)   set x $CONFIG_FILES ;;
+  esac
   shift
-  # Used to flag and report bootstrapping failures.
-  am_rc=0
-  for am_mf
+  for mf
   do
     # Strip MF so we end up with the name of the file.
-    am_mf=`AS_ECHO(["$am_mf"]) | sed -e 's/:.*$//'`
-    # Check whether this is an Automake generated Makefile which includes
-    # dependency-tracking related rules and includes.
-    # Grep'ing the whole file directly is not great: AIX grep has a line
+    mf=`echo "$mf" | sed -e 's/:.*$//'`
+    # Check whether this is an Automake generated Makefile or not.
+    # We used to match only the files named 'Makefile.in', but
+    # some people rename them; so instead we look at the file content.
+    # Grep'ing the first line is not enough: some people post-process
+    # each Makefile.in and add a new line on top of each file to say so.
+    # Grep'ing the whole file is not good either: AIX grep has a line
     # limit of 2048, but all sed's we know have understand at least 4000.
-    sed -n 's,^am--depfiles:.*,X,p' "$am_mf" | grep X >/dev/null 2>&1 \
-      || continue
-    am_dirpart=`AS_DIRNAME(["$am_mf"])`
-    am_filepart=`AS_BASENAME(["$am_mf"])`
-    AM_RUN_LOG([cd "$am_dirpart" \
-      && sed -e '/# am--include-marker/d' "$am_filepart" \
-        | $MAKE -f - am--depfiles]) || am_rc=$?
+    if sed -n 's,^#.*generated by automake.*,X,p' "$mf" | grep X >/dev/null 2>&1; then
+      dirpart=`AS_DIRNAME("$mf")`
+    else
+      continue
+    fi
+    # Extract the definition of DEPDIR, am__include, and am__quote
+    # from the Makefile without running 'make'.
+    DEPDIR=`sed -n 's/^DEPDIR = //p' < "$mf"`
+    test -z "$DEPDIR" && continue
+    am__include=`sed -n 's/^am__include = //p' < "$mf"`
+    test -z "$am__include" && continue
+    am__quote=`sed -n 's/^am__quote = //p' < "$mf"`
+    # Find all dependency output files, they are included files with
+    # $(DEPDIR) in their names.  We invoke sed twice because it is the
+    # simplest approach to changing $(DEPDIR) to its actual value in the
+    # expansion.
+    for file in `sed -n "
+      s/^$am__include $am__quote\(.*(DEPDIR).*\)$am__quote"'$/\1/p' <"$mf" | \
+	 sed -e 's/\$(DEPDIR)/'"$DEPDIR"'/g'`; do
+      # Make sure the directory exists.
+      test -f "$dirpart/$file" && continue
+      fdir=`AS_DIRNAME(["$file"])`
+      AS_MKDIR_P([$dirpart/$fdir])
+      # echo "creating $dirpart/$file"
+      echo '# dummy' > "$dirpart/$file"
+    done
   done
-  if test $am_rc -ne 0; then
-    AC_MSG_FAILURE([Something went wrong bootstrapping makefile fragments
-    for automatic dependency tracking.  If GNU make was not used, consider
-    re-running the configure script with MAKE="gmake" (or whatever is
-    necessary).  You can also try re-running configure with the
-    '--disable-dependency-tracking' option to at least be able to build
-    the package (albeit without support for automatic dependency tracking).])
-  fi
-  AS_UNSET([am_dirpart])
-  AS_UNSET([am_filepart])
-  AS_UNSET([am_mf])
-  AS_UNSET([am_rc])
-  rm -f conftest-deps.mk
 }
 ])# _AM_OUTPUT_DEPENDENCY_COMMANDS
 
@@ -390,17 +397,18 @@ AC_DEFUN([_AM_OUTPUT_DEPENDENCY_COMMANDS],
 # -----------------------------
 # This macro should only be invoked once -- use via AC_REQUIRE.
 #
-# This code is only required when automatic dependency tracking is enabled.
-# This creates each '.Po' and '.Plo' makefile fragment that we'll need in
-# order to bootstrap the dependency handling code.
+# This code is only required when automatic dependency tracking
+# is enabled.  FIXME.  This creates each '.P' file that we will
+# need in order to bootstrap the dependency handling code.
 AC_DEFUN([AM_OUTPUT_DEPENDENCY_COMMANDS],
 [AC_CONFIG_COMMANDS([depfiles],
      [test x"$AMDEP_TRUE" != x"" || _AM_OUTPUT_DEPENDENCY_COMMANDS],
-     [AMDEP_TRUE="$AMDEP_TRUE" MAKE="${MAKE-make}"])])
+     [AMDEP_TRUE="$AMDEP_TRUE" ac_aux_dir="$ac_aux_dir"])
+])
 
 # Do all the work for Automake.                             -*- Autoconf -*-
 
-# Copyright (C) 1996-2020 Free Software Foundation, Inc.
+# Copyright (C) 1996-2017 Free Software Foundation, Inc.
 #
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
@@ -487,8 +495,8 @@ AC_REQUIRE([AM_PROG_INSTALL_STRIP])dnl
 AC_REQUIRE([AC_PROG_MKDIR_P])dnl
 # For better backward compatibility.  To be removed once Automake 1.9.x
 # dies out for good.  For more background, see:
-# <https://lists.gnu.org/archive/html/automake/2012-07/msg00001.html>
-# <https://lists.gnu.org/archive/html/automake/2012-07/msg00014.html>
+# <http://lists.gnu.org/archive/html/automake/2012-07/msg00001.html>
+# <http://lists.gnu.org/archive/html/automake/2012-07/msg00014.html>
 AC_SUBST([mkdir_p], ['$(MKDIR_P)'])
 # We need awk for the "check" target (and possibly the TAP driver).  The
 # system "awk" is bad on some platforms.
@@ -555,7 +563,7 @@ END
 Aborting the configuration process, to ensure you take notice of the issue.
 
 You can download and install GNU coreutils to get an 'rm' implementation
-that behaves properly: <https://www.gnu.org/software/coreutils/>.
+that behaves properly: <http://www.gnu.org/software/coreutils/>.
 
 If you want to complete the configuration process using your problematic
 'rm' anyway, export the environment variable ACCEPT_INFERIOR_RM_PROGRAM
@@ -597,7 +605,7 @@ for _am_header in $config_headers :; do
 done
 echo "timestamp for $_am_arg" >`AS_DIRNAME(["$_am_arg"])`/stamp-h[]$_am_stamp_count])
 
-# Copyright (C) 2001-2020 Free Software Foundation, Inc.
+# Copyright (C) 2001-2017 Free Software Foundation, Inc.
 #
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
@@ -618,7 +626,7 @@ if test x"${install_sh+set}" != xset; then
 fi
 AC_SUBST([install_sh])])
 
-# Copyright (C) 1998-2020 Free Software Foundation, Inc.
+# Copyright (C) 1998-2017 Free Software Foundation, Inc.
 #
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
@@ -639,7 +647,7 @@ fi])
 # Add --enable-maintainer-mode option to configure.         -*- Autoconf -*-
 # From Jim Meyering
 
-# Copyright (C) 1996-2020 Free Software Foundation, Inc.
+# Copyright (C) 1996-2017 Free Software Foundation, Inc.
 #
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
@@ -674,7 +682,7 @@ AC_MSG_CHECKING([whether to enable maintainer-specific portions of Makefiles])
 
 # Check to see how 'make' treats includes.	            -*- Autoconf -*-
 
-# Copyright (C) 2001-2020 Free Software Foundation, Inc.
+# Copyright (C) 2001-2017 Free Software Foundation, Inc.
 #
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
@@ -682,42 +690,49 @@ AC_MSG_CHECKING([whether to enable maintainer-specific portions of Makefiles])
 
 # AM_MAKE_INCLUDE()
 # -----------------
-# Check whether make has an 'include' directive that can support all
-# the idioms we need for our automatic dependency tracking code.
+# Check to see how make treats includes.
 AC_DEFUN([AM_MAKE_INCLUDE],
-[AC_MSG_CHECKING([whether ${MAKE-make} supports the include directive])
-cat > confinc.mk << 'END'
+[am_make=${MAKE-make}
+cat > confinc << 'END'
 am__doit:
-	@echo this is the am__doit target >confinc.out
+	@echo this is the am__doit target
 .PHONY: am__doit
 END
+# If we don't find an include directive, just comment out the code.
+AC_MSG_CHECKING([for style of include used by $am_make])
 am__include="#"
 am__quote=
-# BSD make does it like this.
-echo '.include "confinc.mk" # ignored' > confmf.BSD
-# Other make implementations (GNU, Solaris 10, AIX) do it like this.
-echo 'include confinc.mk # ignored' > confmf.GNU
-_am_result=no
-for s in GNU BSD; do
-  AM_RUN_LOG([${MAKE-make} -f confmf.$s && cat confinc.out])
-  AS_CASE([$?:`cat confinc.out 2>/dev/null`],
-      ['0:this is the am__doit target'],
-      [AS_CASE([$s],
-          [BSD], [am__include='.include' am__quote='"'],
-          [am__include='include' am__quote=''])])
-  if test "$am__include" != "#"; then
-    _am_result="yes ($s style)"
-    break
-  fi
-done
-rm -f confinc.* confmf.*
-AC_MSG_RESULT([${_am_result}])
-AC_SUBST([am__include])])
-AC_SUBST([am__quote])])
+_am_result=none
+# First try GNU make style include.
+echo "include confinc" > confmf
+# Ignore all kinds of additional output from 'make'.
+case `$am_make -s -f confmf 2> /dev/null` in #(
+*the\ am__doit\ target*)
+  am__include=include
+  am__quote=
+  _am_result=GNU
+  ;;
+esac
+# Now try BSD make style include.
+if test "$am__include" = "#"; then
+   echo '.include "confinc"' > confmf
+   case `$am_make -s -f confmf 2> /dev/null` in #(
+   *the\ am__doit\ target*)
+     am__include=.include
+     am__quote="\""
+     _am_result=BSD
+     ;;
+   esac
+fi
+AC_SUBST([am__include])
+AC_SUBST([am__quote])
+AC_MSG_RESULT([$_am_result])
+rm -f confinc confmf
+])
 
 # Fake the existence of programs that GNU maintainers use.  -*- Autoconf -*-
 
-# Copyright (C) 1997-2020 Free Software Foundation, Inc.
+# Copyright (C) 1997-2017 Free Software Foundation, Inc.
 #
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
@@ -756,7 +771,7 @@ fi
 
 # Helper functions for option handling.                     -*- Autoconf -*-
 
-# Copyright (C) 2001-2020 Free Software Foundation, Inc.
+# Copyright (C) 2001-2017 Free Software Foundation, Inc.
 #
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
@@ -785,7 +800,7 @@ AC_DEFUN([_AM_SET_OPTIONS],
 AC_DEFUN([_AM_IF_OPTION],
 [m4_ifset(_AM_MANGLE_OPTION([$1]), [$2], [$3])])
 
-# Copyright (C) 1999-2020 Free Software Foundation, Inc.
+# Copyright (C) 1999-2017 Free Software Foundation, Inc.
 #
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
@@ -832,7 +847,7 @@ AC_LANG_POP([C])])
 # For backward compatibility.
 AC_DEFUN_ONCE([AM_PROG_CC_C_O], [AC_REQUIRE([AC_PROG_CC])])
 
-# Copyright (C) 2001-2020 Free Software Foundation, Inc.
+# Copyright (C) 2001-2017 Free Software Foundation, Inc.
 #
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
@@ -851,7 +866,7 @@ AC_DEFUN([AM_RUN_LOG],
 
 # Check to make sure that the build environment is sane.    -*- Autoconf -*-
 
-# Copyright (C) 1996-2020 Free Software Foundation, Inc.
+# Copyright (C) 1996-2017 Free Software Foundation, Inc.
 #
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
@@ -932,7 +947,7 @@ AC_CONFIG_COMMANDS_PRE(
 rm -f conftest.file
 ])
 
-# Copyright (C) 2009-2020 Free Software Foundation, Inc.
+# Copyright (C) 2009-2017 Free Software Foundation, Inc.
 #
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
@@ -992,7 +1007,7 @@ AC_SUBST([AM_BACKSLASH])dnl
 _AM_SUBST_NOTMAKE([AM_BACKSLASH])dnl
 ])
 
-# Copyright (C) 2001-2020 Free Software Foundation, Inc.
+# Copyright (C) 2001-2017 Free Software Foundation, Inc.
 #
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
@@ -1020,7 +1035,7 @@ fi
 INSTALL_STRIP_PROGRAM="\$(install_sh) -c -s"
 AC_SUBST([INSTALL_STRIP_PROGRAM])])
 
-# Copyright (C) 2006-2020 Free Software Foundation, Inc.
+# Copyright (C) 2006-2017 Free Software Foundation, Inc.
 #
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
@@ -1039,7 +1054,7 @@ AC_DEFUN([AM_SUBST_NOTMAKE], [_AM_SUBST_NOTMAKE($@)])
 
 # Check how to create a tarball.                            -*- Autoconf -*-
 
-# Copyright (C) 2004-2020 Free Software Foundation, Inc.
+# Copyright (C) 2004-2017 Free Software Foundation, Inc.
 #
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
-- 
2.35.1

Re: binutils as policy checker (was: RFC: Add a linker warning when creating segments with RWX permissions)

[Matthias Klose]

On 03.05.22 21:57, H.J. Lu wrote:
> On Tue, May 3, 2022 at 12:35 PM Matthias Klose <doko@ubuntu.com> wrote:
>>
>> On 28.04.22 11:46, Nick Clifton via Binutils wrote:
>>> Hi Guys,
>>>
>>>     OK, attached is v2 of my proposed patch.  The main features of this
>>>     new version are:
>>>
>>>       * There are now configure options which can turn off the generation
>>>         of linker warnings about the creation of executable segments and
>>>         the creation of executable stacks.  By default however not using
>>>         these configure options will result in the creation of a linker
>>>         with all of the warnings enabled.
>>>
>>>       * There is new linker command line option: --no-warn-rwx-segments
>>>         which disables the warnings about executable segments.
>>>
>>>       * There are tests for the new features, plus extra regexps in the
>>>         testsuite's pruning proc to remove the warnings from the linker's
>>>         output for normal tests.
>>>
>>>       * The creation of a TLS segment with eXecute permission will trigger
>>>         a warning, regardless of whether it has the read and/or write
>>>         permissions set.
>>>
>>>       * There is a new configure time option which will disable the
>>>         creation of an executable stack simply because an input file is
>>>         missing a .note-GNU-stack section (for those architectures where
>>>         such a creation is the normal behaviour).  This option is not
>>>         enabled by default however.  At least not yet.
>>>
>>>     I think that this represents the best compromise between helping to
>>>     promote secure builds whilst also allowing toolchain creators and
>>>     program builders the option to disable the features if they wish.
>>>
>>>     Any comments ?
>>
>> this commit contains a ld/aclocal.m4 generated with automake 1.16.  Please
>> re-create that file with automake 1.15.1. And maybe re-create the Makefile.in
>> also with the correct automake version.
>>
>> Thanks, Matthias
> 
> I am checking in this.

thanks, I see that zlib also processed with automake 1.16..2

Matthias