[Starlingx-discuss] Recommended C/C++ compiler flag for security
Cabrales, Ada
ada.cabrales at intel.com
Mon Jan 21 21:51:13 UTC 2019
Comments inline
> -----Original Message-----
> From: Young, Ken [mailto:Ken.Young at windriver.com]
> Sent: Friday, January 18, 2019 9:34 AM
> To: Victor Rodriguez <vm.rod25 at gmail.com>
> Cc: starlingx-discuss at lists.starlingx.io
> Subject: Re: [Starlingx-discuss] Recommended C/C++ compiler flag for
> security
>
> See inline.
>
> On 2019-01-17, 5:34 PM, "Victor Rodriguez" <vm.rod25 at gmail.com> wrote:
>
> On Wed, Jan 2, 2019 at 10:35 AM Young, Ken
> <Ken.Young at windriver.com> wrote:
> >
> > Victor,
> >
> >
> >
> > Security work is never completed. There is always a long list of inventive
> new vulnerabilities and a laundry list of hardening work to be completed.
> The vulnerability work, considering the severity, is generally urgent.
> Hardening work is not urgent but important. In this case, we are dealing with
> a hardening initiative that focuses on a small area of the code.
> >
> >
> >
> > The challenge is that these small change proposed have larger
> implications. As was pointed out on the gerrit reviews, performance and / or
> functional testing is required.
>
> Hi Ken
>
> Just to follow the idea of this mail after hollliday break, you mention that:
>
> My concern is that we affect the timing / behaviour of stx-ha and
> stx-metal such that they do not work together in some scenarios. This
> will need to be tested and is certainly larger than a sanity.
>
> Could you please help to describe n human words, ( I can do the script
> ) how a good test to probe this would look like?
> If you provide me with a basic description of the security test I
> could help writing the first draft of a code test that help us to
> prove if the flags break the functionality
>
> Victor,
>
> At a high level, we need to regress the behaviour of stx-ha and stx-metal to
> ensure that there is functional issues introduced by the change to the
> compiler. As well, we need to look at the system behaviour of ha and metal
> to ensure no changes have been introduced which affect has behaviour:
>
> - SWACT detection and time
> - Multinode failure avoidance
> - Heartbeat loss
> - lock / unlock
> - etc
>
> I believe that Ada has the test for ha and metal. Please review.
>
Yes, we executed several test cases covering what Ken mentions (manually). What I'm not sure is about heartbeat loss, but let me check.
What we can do is to build a test plan and submit it for revision. When do you need it (and please, don't say tomorrow)?
Ada
> Regards,
> Ken Y
>
> thanks
>
> Victor R
> >
> >
> >
> > Also, I am wondering if there is a way to phase the effort. For example, is
> there a way to break up the flag changes such that the warnings are
> separated from the flags which change the compiled code? That way, we
> are not trying to jam everything through at once.
> >
> >
> >
> > Hope this helps. Happy to discuss when you return from Holliday.
> >
> >
> >
> > Regards,
> >
> > Ken Y
> >
> >
> >
> > From: Victor Rodriguez <vm.rod25 at gmail.com>
> > Date: Friday, December 28, 2018 at 7:34 PM
> > To: Curtis <serverascode at gmail.com>
> > Cc: "starlingx-discuss at lists.starlingx.io" <starlingx-
> discuss at lists.starlingx.io>
> > Subject: Re: [Starlingx-discuss] Recommended C/C++ compiler flag for
> security
> >
> >
> >
> >
> >
> > 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_ex
> ercises/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
>
>
> _______________________________________________
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
More information about the Starlingx-discuss
mailing list