[Scons-users] How to simultaneously build pie executables and pic shared libraries?

Andrew C. Morrow andrew.c.morrow at gmail.com
Fri Oct 30 10:05:11 EDT 2015


Thanks Bill -

That could probably work, however, that approach does have some problems in
general. Notably, it doesn't compose. If tool A wants to replace Program
with a customized builder, and tool also B wants also to replace Program
with a different builder, you can't use tool A and tool B in the same
project.

I'll keep thinking about it. For now, I only really need this to work in
the static linking case, which I think I can do reasonably easily, but of
course I'd like to ultimately extend it to the dynamic case as well.

Thanks,
Andrew



On Sat, Oct 24, 2015 at 5:15 PM, Bill Deegan <bill at baddogconsulting.com>
wrote:

> Andrew,
>
> For setting up the environment for ASLR you can  us a PseudoBuilder
> ( see:
> http://scons.org/doc/production/HTML/scons-user.html#chap-add-method )
>
> Is the following correct?
> c->o  for inclusion in shared libraries  -fpic
> c->o for inclusion in programs/static libraries -fpie
> .o's->.so  not -fpie
> .o's & .so's ->  binaries -fpie
>
> Here's the what sets up the program builder (from
> SCons/Tool/__init__.py).  I think you could put this in your ASLR pseudo
> builder and change the action so the build string used whatever
> variables/flags you want. Based on the LinkAction or ShLinkAction strings..
> def createProgBuilder(env):
>     """This is a utility function that creates the Program
>     Builder in an Environment if it is not there already.
>
>     If it is already there, we return the existing one.
>     """
>
>     try:
>         program = env['BUILDERS']['Program']
>     except KeyError:
>         import SCons.Defaults
>         program = SCons.Builder.Builder(action = SCons.Defaults.LinkAction,
>                                         emitter = '$PROGEMITTER',
>                                         prefix = '$PROGPREFIX',
>                                         suffix = '$PROGSUFFIX',
>                                         src_suffix = '$OBJSUFFIX',
>                                         src_builder = 'Object',
>                                         target_scanner = ProgramScanner)
>         env['BUILDERS']['Program'] = program
>
>     return program
>
>
>
> -Bill
>
> On Sat, Oct 24, 2015 at 6:17 AM, Andrew C. Morrow <
> andrew.c.morrow at gmail.com> wrote:
>
>>
>> Hi Bill -
>>
>> Thanks for the suggestions, some comments below:
>>
>>
>>>
>>> Any reason you couldn't use several different environments with the
>>> flags set as you want and
>>>
>>
>> I'd need at least two distinct named top level Environments, one for
>> Programs, and one for Libraries, and then users would need to import and
>> export those as appropriate across ~70 SConscript files. My users (other
>> developers) are going to get it wrong somewhere. They are very accustomed
>> to writing env.Program or env.Library (Library is overridden to call either
>> env.StaticLibrary or env.SharedLibrary depending on a global build switch).
>> With this approach, they would need to remember to call program_env.Program
>> and library_env.Library. That seems redundant.
>>
>> Additionally, were someone to accidentally use the PIE configured
>> Environment to build a shared library it would be an error I think, but if
>> they used the PIC configured Environment to build an executable it would
>> just work, but produce an executable that was not position independent.
>> Tests would all pass, and the security error would likely go unnoticed. I'd
>> rather make it impossible to get wrong by configuring one Environment so
>> that .StaticLibrary, .SharedLibrary, and .Program all did the right thing
>> by construction.
>>
>> I'd also need to find every place that the existing
>> common-to-programs-and-libraries Environment is now cloned, modified, and
>> then used to create several programs and libraries, and do that twice, once
>> for the Program Environment, and once for the Library Environment. That
>> seems fragile.
>>
>>
>>> then use the appropriate one for each type of file you want to build?
>>> Or you can just specify the flags on the builder:
>>>
>>> env.Program(target,sources,
>>>     PROGCCFLAGS=["-fpie"],
>>>     SHCCFLAGS=["-fpic"],
>>>     PROGLINKFLAGS=["-pie"])
>>>
>>
>> I want to be able to turn ASLR on and off with a build flag, so the
>> decision about whether the flags should be present needs to be made at
>> SCons runtime. Also, not all of the target platforms support the flags, so
>> their use is conditioned on configure checks. Finally, some platforms, like
>> Windows, may have entirely different approaches, or require no
>> configuration at all, like OS X.
>>
>> And, for this to work, I'd still need to introduce PROG*FLAGS into CCCOM
>> and LINKCOM, right? I think if I do that then I can just do the right thing
>> globally. And there are hundreds of .Program and .Library calls, so I don't
>> really want to change them all.
>>
>> Ideally, I'd like this to work as a Tool, so that you can just say
>> env.Tool("ASLR"), and have it modify the 'env' as needed, and then have
>> env.Program (PIE objects, PIE linkflags), env.StaticLibrary (pie objects),
>> and env.SharedLibrary (pic objects, shared library linkflags) do the right
>> thing.
>>
>> SCons for unix like environments is by default set up to consider
>> building shared libraries as "do everything you normally do for programs,
>> but with some extra stuff configured via the SH* flags". But to do ASLR
>> right, pic shared libraries and pie executables are just different. One is
>> not a refinement of the other, nor is it produced via a superset of the
>> other's flags.
>>
>> Which seems to that motivate the introduction of PROG*FLAGS.
>>
>> Thanks for your thoughts!
>>
>> Andrew
>>
>>
>>
>>> -Bill
>>>
>>> On Fri, Oct 23, 2015 at 8:19 PM, Andrew C. Morrow <
>>> andrew.c.morrow at gmail.com> wrote:
>>>
>>>>
>>>> Hi -
>>>>
>>>> I think it is pretty straightforward to get PIE executables with SCons
>>>> if all linking is static:
>>>>
>>>> env.AppendUnique(
>>>>     CCFLAGS=["-fpie"],
>>>>     LINKFLAGS=["-pie"],
>>>> )
>>>>
>>>> How to make it work for a build with both executables and shared
>>>> libraries is not as clear. The problem is that object files destined for
>>>> the shared libraries need to still be built with -fpic and linked as
>>>> normal, but object files destined for the executable need to be built with
>>>> -fpie and then the executable must be linked with -pie:
>>>>
>>>> Doing this:
>>>>
>>>> env.AppendUnique(
>>>>     CCFLAGS=["-fpie"],
>>>>     SHCCFLAGS=["-fpic"],
>>>>     LINKFLAGS=["-pie"],
>>>> )
>>>>
>>>> doesn't work because objects being compiled for shared libraries
>>>> receive both CCFLAGS and SHCCFLAGS. Similarly for linking, where the link
>>>> step for shared libraries gets both LINKFLAGS and SHLINKFLAGS. We
>>>> definitely don't want to pass -pie to our shared library builds, nor do we
>>>> want both -fpie and -fpic on the compile line when building objects for
>>>> shared libraries.
>>>>
>>>> It feels like there is a need for PROG[C|CC|CXX]FLAGS and
>>>> PROGLINKFLAGS? In other words, compiler and linker flags analogous to the
>>>> SH prefixed variants but that are only used when building objects for an
>>>> executable or linking an executable.
>>>>
>>>> One idea I had was to modify CCCOM, CXXCOM, and LINKCOM to honor
>>>> PROGC*FLAGS and PROGLINKFLAGS, though I'm not very excited about it. Then I
>>>> could do this:
>>>>
>>>> env.AppendUnique(
>>>>     PROGCCFLAGS=["-fpie"],
>>>>     SHCCFLAGS=["-fpic"],
>>>>     PROGLINKFLAGS=["-pie"],
>>>> )
>>>>
>>>> Does this seem like a viable path to achieve PIE executables with PIC
>>>> shared libraries, or am I going to run into surprises? Any thoughts on
>>>> other ways to do this? Has anyone managed to make this work?
>>>>
>>>> Thanks,
>>>> Andrew
>>>>
>>>>
>>>> _______________________________________________
>>>> Scons-users mailing list
>>>> Scons-users at scons.org
>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Scons-users mailing list
>>> Scons-users at scons.org
>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>
>>>
>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-users at scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>>
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20151030/4766f3ef/attachment.html>


More information about the Scons-users mailing list