Re: [boost] Enabling spectre mitigation in boost libraries

Subject: Re: [boost] Enabling spectre mitigation in boost libraries
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2019-04-06 17:30:56

On 4/6/19 7:46 PM, John Maddock via Boost wrote:
> 
> On 05/04/2019 00:52, Riff J via Boost wrote:
>> Hi everyone,
>>
>> I am a developer from Microsoft and currently using boost in our project.
>> We recently get noticed by our security team, that the boost library we
>> use, are not compiled with spectre mitigation (/Qspectre) enabled. Since
>> boost is super powerful, it might not be a good idea to write our own or
>> maintain our own version, so we are reaching out for help. Could anyone
>> please help see if we could enable /Qspectre option in the official build
>> of boost?
> 
> We tend to use default compiler flags for official builds, but it's 
> relatively easy for you to build Boost with whatever other flags you may 
> want:
> 
> cd boost-root-dir
> 
> bootstrap
> 
> b2 --build-type=complete cxxflags=-Qspectre
> 
> Will build the libraries with the latest installed msvc version and the 
> /Qspectre flag enabled.  And of course for header only libraries you 
> don't need to do anything at all anyway.
> 
> One thing we could look at for future releases would be to provide 
> differently-named binaries for /Qspectre.  Anyone else have thoughts on 
> that?

I don't think replacing built binaries with Spectre-protected ones is 
what we want, but adding them as an option might be possible. However, 
doubling the number of configurations of the built libraries would be 
too taxing. E.g. one package of Boost 1.69 (which corresponds to one 
version of MSVC at one bitness) is already 200-250 MiB, and that would 
have to double for the newer MSVC versions that support the flag. If 
we're going to package these binaries, maybe we should package them 
separately.

As for whether we should actually provide such binaries, I'm not sure. 
I've never used the pre-built binaries. I would guess anyone working on 
security-sensitive software would want to build everything from source 
code (ideally, after reviewing the said source code), so I'm not sure 
how useful those binaries would be.