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

Bill Deegan bill at baddogconsulting.com
Sat Oct 24 17:15:15 EDT 2015 

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20151024/c46bbc02/attachment-0001.html>

More information about the Scons-users mailing list