[Starlingx-discuss] Recommended C/C++ compiler flag for security

Victor Rodriguez vm.rod25 at gmail.com
Sat Dec 29 00:32:53 UTC 2018


On Fri, Dec 21, 2018, 07:08 Curtis <serverascode at gmail.com wrote:

>
>
> On Thu, Dec 20, 2018 at 3:47 PM Victor Rodriguez <vm.rod25 at gmail.com>
> wrote:
>
>> Hi StarlingX community
>>
>> We can all agree that security is an important feature to be taken
>> into consideration in any SW project. In the aim of improving the
>> security of the StarlingX project, we have been taking the task to
>> propose the use of some compiler flags that prevent and detect some
>> security holes, especially by buffer overflow that could lead into ROP
>> attacks.
>>
>> The list of flags that we are proposing are :
>>
>> Stack-based Buffer Overrun Detection:    CFLAGS=”-fstack-protector-strong”
>>
>> Fortify source:                          CFLAGS="-O2 -D_FORTIFY_SOURCE=2"
>> Format string vulnerabilities:          CFLAGS="-Wformat
>> -Wformat-security"
>> Stack execution protection:              LDFLAGS="-z noexecstack"
>> Data relocation and protection (RELRO): LDLFAGS="-z relro -z now"
>>
>>
>> These are being analyzed in the following Gerrit reviews (thanks a lot
>> for all the good feedback)
>>
>> https://review.openstack.org/#/c/623608/
>> https://review.openstack.org/#/c/623603/
>> https://review.openstack.org/#/c/623601/
>> https://review.openstack.org/#/c/623599/
>>
>> As requested in the Gerrit reviews, there is a proper need to first
>> understand what these compiler flags do and what is the impact they
>> have at the functional and performance area of the project. This is a
>> preliminary report, we will be following up with a test plan for
>> functional & performance test plans for the services as a next step.
>> This report includes:
>>
>> * Detailed description of what the compiler flag does
>> * Code example that shows how does it work to prevent attacks
>> * If there is a change in the binary, we create a microbenchmark that
>> shows us how the flag impact the performance
>>
>>
>> https://github.com/VictorRodriguez/hobbies/tree/master/c_programing_exercises/cflags_security
>>
>> As a result of the microbenchmark, the performance impact is not
>> relevant ( less than 1% ) using an Ubuntu x86 system ( GCC 5 ) (more
>> details on the HW and SW specification upon requests)
>>
>> The areas of the code we are suggesting on the patches are:
>>
>> * stx-ha
>> * stx-metal
>> * stx-nfv
>> * stx-fault
>>
>> We do take care that these flags are not breaking the following areas
>> after being applied.
>>
>> * Build process of the image
>> * Sanity test cases after the image is created
>> (Ada can give more details on the sanity report of the image generated
>> with these flags)
>>
>> If running the sanity tests are not enough to prove that a change in
>> compiler flags do not affect functionality, please gave us the right
>> path to follow.
>>
>> As mentioned before, this is a preliminary report, and that we will be
>> following up with a test plan for functional & performance test plans
>> for the services as a next step.
>>
>> Hope this email helps to clarify some questions related to the flags
>> and start the follow-up discussion.
>>
>
> Thanks for the context Victor, it's very helpful to me.
>

Hi Curtis, glad it helps, it was fun to do the research

>
> One thing I want to mention is something the Kata Containers team was
> talking about at the Berlin OpenStack summit, which is when many small
> performance hits start to add up. They have to be careful to ensure they
> don't have a bunch of smallish looking changes that add up to a large
> performance hit over a longer period of time.
>

You are right, it's a valid point that we need to take care too

>
> Overall I'm sure the StarlingX project would like to have some performance
> testing, if we don't already, though that can be challenging for an open
> source project. I had mentioned OPNFV's Functest and related projects on
> the TSC call, but now seeing which components are affected I'm not sure
> that would be directly helpful. I look forward to further discussions
> around this area.
>

Thanks for let me know that, I will take a look at OPNFV's functest and
other projects before the next TSC of 2019

I will do my best to came up with a proposal for a better performance
testing.

Thanks

Victor Rodriguez

>
> Thanks,
> Curtis
>
>
>>
>> Regards
>>
>> Victor Rodriguez
>>
>> _______________________________________________
>> Starlingx-discuss mailing list
>> Starlingx-discuss at lists.starlingx.io
>> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
>>
>
>
> --
> Blog: serverascode.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20181228/f776c87a/attachment.html>


More information about the Starlingx-discuss mailing list