Re: Stage3 closing soon, call for patch pings
On 15/01/15 04:26 PM, H.J. Lu wrote: > On Thu, Jan 15, 2015 at 1:04 PM, Jeff Law wrote: >> >> Stage3 is closing rapidly. I've drained my queue of patches I was tracking >> for gcc-5.However, note that I don't track everything. If it's a patch >> for a backend, language other than C or seemingly has another maintainer >> that's engaged in review, then I haven't been tracking the patch. >> >> So this is my final call for patch pings. I've got some bandwidth and may >> be able to look at a few patches that have otherwise stalled. >> > > This one was updated yesterday: > > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00956.html > > I guess it won't hurt to list it here. I find it pretty strange that this didn't land. It's a dead simple set of changes since the subtle fixes already landed. MSVC has offered full ASLR by default since the early Vista era, but most Linux distributions don't have it thanks to GCC making it difficult to use. Anyway, here's to another year of unmitigated exploits... signature.asc Description: OpenPGP digital signature
Re: [PING][PATCH][1-3] New configure options that make the compiler use -fPIE and -pie as default option
On 09/01/15 07:58 AM, Richard Biener wrote:
>
> Looking at the actual implementation I wonder why it's not similar
> to how darwin gets at it default (not sure how it does). Also
> looking at how DRIVER_SELF_SPECS is used I wonder if the
> functionality can be enabled with a simple
>
> --with-specs="%{pie|fpic|fPIC|fpie|fPIE|fno-pic|fno-PIC|fno-pie|fno-PIE|shared|static|nostdlib|nodefaultlibs|nostartfiles:;:-fPIE
> -pie}"
>
> at configure time (using CONFIGURE_SPECS).
>
> I have no idea if the above is really the proper spec to use - why
> do you include static, nostdlib, nodefaultlibs and nostartfiles
> for example? Similar, if I say
PIE isn't supported for static executables by binutils, etc. so it
does need to exclude that. The checks for nostdlib, nodefaultlibs
and nostartfiles do seem unnecessary. I think distributions include
those in the existing wrapper scripts and GCC patches because it
avoids the need for patching build systems for kernel / freestanding
code to include -fno-pie, but it's more correct to leave these out.
> gcc -pie -c t.c
>
> we will end up with a non-PIE object, and linking with -fPIE will
> end up with a DYN_EXEC object.
>
> I believe you want to treat link and compile arguments separately
> (and adjust the link spec for linking). I also would have said that
> elfos.h is more appropriate than gnu-user.h, but ...
Handling it separately is what the existing wrapper scripts for this do:
-fno-PIC|-fno-pic|-fno-PIE|-fno-pie|-static|--static|-shared|--shared)
force_fPIE=0
force_pie=0
;;
-fPIC|-fpic|-fPIE|-fpie)
force_fPIE=0
;;
-c|-E|-S)
force_pie=0
;;
I think it's appropriate for it to
> That said, the patch looks more like a hack (and see above how
> to achieve the same without a patch(?)), not like a proper implementation
> of a PIE default.
I don't think it can be considered a hack if it's handling all of the cases
correctly, so it might need some changes from the current implementation but
that doesn't make it a dead end. Is it actually done in a significantly
different way for OS X?
If it can be done by passing --with-specs to configure then that could be a
viable alternative for distributions that do not want to add GCC patches or
use wrapper scripts (Arch Linux) but I'm not sure that it will fly.
signature.asc
Description: OpenPGP digital signature
Re: [PING][PATCH][1-3] New configure options that make the compiler use -fPIE and -pie as default option
On 09/01/15 12:49 PM, Joseph Myers wrote:
> On Fri, 9 Jan 2015, Daniel Micay wrote:
>
>>> --with-specs="%{pie|fpic|fPIC|fpie|fPIE|fno-pic|fno-PIC|fno-pie|fno-PIE|shared|static|nostdlib|nodefaultlibs|nostartfiles:;:-fPIE
>>> -pie}"
>>>
>>> at configure time (using CONFIGURE_SPECS).
>>>
>>> I have no idea if the above is really the proper spec to use - why
>>> do you include static, nostdlib, nodefaultlibs and nostartfiles
>>> for example? Similar, if I say
>>
>> PIE isn't supported for static executables by binutils, etc. so it
>> does need to exclude that. The checks for nostdlib, nodefaultlibs
>
> Well - that would indicate excluding -pie if one of the link-time options
> conflicting with it is used, -fPIE if one of the compile-time options
> conflicting with it is used. That way, "gcc -static file.c" would still
> have the same effect as "gcc -c file.c; gcc -static file.o" (building a
> PIE object, linking it into a non-PIE static executable), which makes
> logical sense to me (although there may be no great benefit either way).
Sure, I agree. It should have separate lists of exceptions for both of
these.
signature.asc
Description: OpenPGP digital signature
Re: [PING][PATCH][1-3] New configure options that make the compiler use -fPIE and -pie as default option
This branch works well for me. It doesn't automatically turn off the linker flag when -fno-PIE or -fno-PIC are passed like most of the wrapper scripts / downstream patches do, but that might not be a problem in practice. signature.asc Description: OpenPGP digital signature
Re: [PING][PATCH][1-3] New configure options that make the compiler use -fPIE and -pie as default option
On 11/01/15 03:52 AM, Daniel Micay wrote: > This branch works well for me. It doesn't automatically turn off the > linker flag when -fno-PIE or -fno-PIC are passed like most of the > wrapper scripts / downstream patches do, but that might not be a problem > in practice. Er, Thunderbird did a terrible job handling my manual reply (wasn't subscribed to the list). Sorry about that. For clarity, this is about H.J. Lu's branch at: https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/hjl/pie signature.asc Description: OpenPGP digital signature
Re: [PING][PATCH][1-3] New configure options that make the compiler use -fPIE and -pie as default option
On 11/01/15 06:37 AM, H.J. Lu wrote: > On Sun, Jan 11, 2015 at 1:05 AM, Daniel Micay wrote: >> On 11/01/15 03:52 AM, Daniel Micay wrote: >>> This branch works well for me. It doesn't automatically turn off the >>> linker flag when -fno-PIE or -fno-PIC are passed like most of the >>> wrapper scripts / downstream patches do, but that might not be a problem >>> in practice. > > -fno-PIE and -fno-PIC aren't linking options. We don't turn on PIE with > > # gcc -fPIE > > You need to use > > # gcc -pie -fPIE > > To turn off PIE, you should use > > # gcc -no-pie -fno-PIE Yeah, it's cleaner this way. Disabling the linker option when the reloc model is known to be incompatible might be a bit too magical. I don't expect that it avoids many compatibility issues anyway. As implemented it's more than good enough to allow distributions to enable PIE across the board which is all I care about :). signature.asc Description: OpenPGP digital signature
