Re: [boost] Enabling spectre mitigation in boost libraries

Subject: Re: [boost] Enabling spectre mitigation in boost libraries
From: Riff J (r12f.code_at_[hidden])
Date: 2019-04-07 16:27:18

On Sun, Apr 7, 2019 at 9:11 AM Rainer Deyke via Boost
<boost_at_[hidden]> wrote:
>
> Like I said, I'm mostly neutral on the issue of whether spectre
> mitigation should be turned on by default or not.  I just find it
> strange that someone from Microsoft should complain about Boost being
> compiled with the compiler options that someone else at Microsoft
> decided to make the default options for that compiler.  From an outsider
> perspective, it looks like a case of the right hand not knowing what the
> left hand is doing.
>
First, sorry, I need to apologize for mentioning I am working in
Microsoft, as it might give you all a wrong impression that I speak
for Microsoft. I was not doing that. I am just a regular developer
trying to fix the project I am working on...

All the replies in this thread makes me re-evaluate how serve this
issue is. I thought this is a really severe one. Although /Qspectre
flag is not magic can fix everything, it is a low hanging fruit and
good to have. So instead of just fixing my project, I decided to start
this thread and see if we can add this flavor and benefit others as
well (compiling boost does take time.... although I have already done
it for what I considered as a short term solution for my project).

But what Rene, Rainer and Niall said below noticed me and I cannot
agree more. Although I am not a security expert, I can still imagine
security is a long fight. And there will be more issues and more fixes
in the future. It is up to the compiler team and user to decide which
one to enable, and we cannot satisfy all the cases, e.g. control flow
guard is good to have but not enabled by default as well. While some
people are willing to enable more checks or even add their own, some
people might not even want stack check enabled as their program is so
time sensitive and maybe only runs on their local machine. Providing
pre-compiled binaries with all default flags while having a way for
user to build their own flavor is definitely good enough. And this is
what boost has already done.

And thank you all again for all the help and great discussions!

On Sun, Apr 7, 2019 at 4:03 AM Rainer Deyke via Boost
<boost_at_[hidden]> wrote:
>
> On 07.04.19 04:34, Rene Rivera via Boost wrote:
> > If Microsoft feels
> > this is truly an important concern that needs to be addressed Microsoft
> > could build Boost in that configuration and provide them for the rest of
> > the world to use.
>
> I would go even further than that.  If Microsoft, as an organization,
> feels that libraries should be compiled by with spectre mitigation by
> default, then it's up to the MSVC team to actually make that the
> default, without requiring extra command line arguments.  Asking every
> user of MSVC to modify their build scripts in order to turn on spectre
> mitigation doesn't scale very well when there are millions of such users.
>

On Sun, Apr 7, 2019 at 1:21 AM Niall Douglas via Boost
<boost_at_[hidden]> wrote:
>
> Security conscious end users are going to recompile everything according
> to their own verification and audit processes in any case. They won't
> use precompiled binaries from external parties unless utterly unavoidable.
>
> So to me, apart from fixing the build errors mentioned when compiling
> with spectre mitigations enabled (pull requests welcome), this is not an
> issue the release managers need solve.
>

On Sun, Apr 7, 2019 at 9:11 AM Rainer Deyke via Boost
<boost_at_[hidden]> wrote:
>
> On 07.04.19 16:10, degski via Boost wrote:
> > The best way to drive a bicycle is obviously with side-wheels, a helmet on,
> > knee paddings and to never leave your drive-way. Once the [a] lib is
> > compiled with Spectre-Mitigations, there is no way of "turning it off". In
> > reality the problem is highly hypothetical as most (Windows) Boost users
> > seem to prefer to use out-dated compilers [and out-dated Boost for that
> > matter] and will not [be able to] use these spectre-mitigated-libs anyway.
>
> Yes, I think we're all aware that any heuristic can lead to absurdity
> when taken to the extreme.  We're also all aware that lots of code is
> shipped with serious security flaws, so clearly a lot of programmers are
> erring on the side of "not enough security".
>
> Like I said, I'm mostly neutral on the issue of whether spectre
> mitigation should be turned on by default or not.  I just find it
> strange that someone from Microsoft should complain about Boost being
> compiled with the compiler options that someone else at Microsoft
> decided to make the default options for that compiler.  From an outsider
> perspective, it looks like a case of the right hand not knowing what the
> left hand is doing.
>
>
> --
> Rainer Deyke (rainerd_at_[hidden])
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost