This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: [PATCH 12/14] Drop explicit stack-protection of pieces of the system.

From: Florian Weimer <fweimer at redhat dot com>
To: Nix <nix at esperi dot org dot uk>, libc-alpha at sourceware dot org
Cc: Nick Alcock <nick dot alcock at oracle dot com>
Date: Fri, 24 Jun 2016 15:24:55 +0200
Subject: Re: [PATCH 12/14] Drop explicit stack-protection of pieces of the system.
Authentication-results: sourceware.org; auth=none
References: <1465297576-10981-1-git-send-email-nix at esperi dot org dot uk> <1465297576-10981-13-git-send-email-nix at esperi dot org dot uk>

On 06/07/2016 01:06 PM, Nix wrote:

From: Nick Alcock <nick.alcock@oracle.com>

This is probably a bad idea: maybe we want to stack-protect some parts
of the system even when ! --enable-stack-protector.  I can easily adjust
the patch to do that (though it'll mean introducing a new variable
analogous to $(stack-protector) but not controlled by the configure
flag.)

But if we wanted to value consistency over security, and use the same
stack-protection configure flag to control everything, this is how we'd
do it!

("Always include at least one patch with something obviously wrong with
it.")

	* login/Makefile (pt_chown-cflags): Remove.
	* nscd/Makefile (CFLAGS-nscd): Likewise.
	* resolv/Makefile (CFLAGS-libresolv): Likewise.

I would like to see this go in. The existing logic is very misleading,particularly in resolv/Makefile, where nss_dns is *not* protected.


Thanks,
Florian

References:
- --enable-stack-protector for glibc, v7
  - From: Nix
- [PATCH 12/14] Drop explicit stack-protection of pieces of the system.
  - From: Nix

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]