https://sourceware.org/bugzilla/show_bug.cgi?id=29263
Nick Clifton <nickc at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nickc at redhat dot com
--- Comment #2 from Nick Clifton <nickc at redhat dot com> ---
(In reply to John David Anglin from comment #0)
Hi David,
> /usr/lib/gcc/hppa-linux-gnu/11/../../../hppa-linux-gnu/crtn.o: missing
> .note.GNU-stack section implies executable stack
> The first warning seems bogus as crtn.o is not an executable file.
But it is an object file which is being linked with others to create an
executable file.
The logic of the .note.GNU-stack section is that its permissions
(read/write/execute) define the permissions needed of the stack segment in the
final executable. Permissions from different .note-GNU-stack sections in
different input object files are ORed together.
In addition, if the section is missing from any of the input object files then
the target specific default permissions are assumed. For the HPPA architecture
the default permissions are read, write and execute. Hence if the
.note.GNU-stack section is missing from *any* input object file the resulting
HPPA executable will end up with an executable stack segment. This is of
course a potential security issue.
> /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a
> future version of the linker
The point of this message is that we are considering changing the behaviour of
the linker so that all targets default to just read/write for their stacks, and
that executable stacks have to be explicitly requested via the .note.GNU-stack
mechanism. (This would match the behaviour of the lld linker).
> On hppa-linux with kernel v5.18 and later, we don't need an executable
> stack for signal support but we still need it for gcc nested functions.
This is already handled by gcc. If an executable stack is needed in order to
support nested functions (or more probably, taking the address of a nested
function), then gcc will generate a .note.GNU-stack section with the read,
write and execute permissions set. The linker will then obligingly create an
executable stack segment. You will still get a warning message however, since
the issue of executable stacks is still present, albeit for a different reason.
The linker's warnings can be suppressed however, either via a run-time command
line option: --no-warn-execstack or a build-time configure option:
--enable-warn-execstack=no.
Is this sufficient ? We could change the configuration option so that it
defaults to disabling the warnings if the target is the HPPA, but I would
prefer not to do that, as it means that a potential security vulnerability will
be ignored by default.
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
