Re: [boost] Enabling spectre mitigation in boost libraries

Subject: Re: [boost] Enabling spectre mitigation in boost libraries
From: Tom Kent (lists_at_[hidden])
Date: 2019-04-07 13:23:37

On Sun, Apr 7, 2019 at 6:02 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.
>
>
As the guy who actually makes the windows binaries available, I've been
following this thread with interest and I'm very much on the fence.

It wouldn't be hard for me to add a  `cxxflags=-Qspectre` to my invocation
(definitely not going to happen for 1.70), but it raises a lot of other
questions.

Are these mitigations something that would provide a broad benefit for many
users, or is it really only applicable to the code being used in web
browsers or other applications that execute arbitrary external code?

What are the performance impacts of this? Some of the patches for
spectre/meltdown had a 30% performance impact on some workloads. However,
this is a completely different thing. If there are near-zero performance
impacts that might tip the balance.

What does it do to the compatibility of generated libraries? If a user is
linking in a boost library that has been compiled with this switch, does
their code also need compile with this switch (I'm guessing no, but want to
be sure).

Conversely, there are "spectre-mitigated libraries" for the c runtime and
such. Do these need to be installed to benefit from this? They aren't
installed by default (in my fresh install of VS 2019). That leads me to
believe that the default for boost should probably remain as-is.

I'm really not in favor of creating a second build of all the libraries (at
least with toolsets 14.1 and 14.2). Some have mentioned breaking up the
libraries into smaller packages, which sounds like a good idea, but is a
lot of work that I don't have the time to take on now. That said the
question then comes down to if I should add the flag to the default build.
Based on MS's unwillingness to do this in their standard library, I think
I'd also be unwilling to do that in the boost binaries.

Thoughts?
Tom