[Python-Dev] SEC: Spectre variant 2: GCC: -mindirect-branch=thunk -mindirect-branch-register

[Antoine Pitrou]

Hi,

Please don't cross-post so heavily.  python-dev is sufficient for this.

If you want to push this forward, I suggest you measure performance of
Python compiled with and without the Spectre mitigation options, and
report the results here.  That will help vendors and packagers decide
whether they want to pursue the route of enabling those options.

Note there are plenty of data-driven conditional jumps in Python.  It
will not be easy to determine which ones are vulnerable to exploiting
through speculative execution of a mispredicted branch.  The bytecode
evaluation loop sounds like a potential attack target, but it's also
performance-sensitive.

Regards

Antoine.


On Sun, 16 Sep 2018 20:29:06 -0400
Wes Turner <wes.turner at gmail.com> wrote:
> Are all current Python builds and C extensions vulnerable to Spectre
> variants {1, 2, *}?
> 
> There are now multiple threads:
> 
> "SEC: Spectre variant 2: GCC: -mindirect-branch=thunk
> -mindirect-branch-register"
> -
> https://mail.python.org/mm3/archives/list/distutils-sig@python.org/thread/4BGE226DB5EWIAT5VCJ75QD5ASOVJZCM/
> - https://mail.python.org/pipermail/python-ideas/2018-September/053473.html
> - https://mail.python.org/pipermail/python-dev/2018-September/155199.html
> 
> 
> Original thread (that I forwarded to security@):
> "[Python-ideas] Executable space protection: NX bit,"
> https://mail.python.org/pipermail/python-ideas/2018-September/053175.html
> > ~ Do trampolines / nested functions in C extensions switch off the NX bit?  
> 
> On Sunday, September 16, 2018, Nathaniel Smith <njs at pobox.com> wrote:
> 
> > On Wed, Sep 12, 2018, 12:29 Joni Orponen <j.orponen at 4teamwork.ch> wrote:
> >  
> >> On Wed, Sep 12, 2018 at 8:48 PM Wes Turner <wes.turner at gmail.com> wrote:
> >>  
> >>> Should C extensions that compile all add
> >>> `-mindirect-branch=thunk -mindirect-branch-register` [1] to mitigate the
> >>> risk of Spectre variant 2 (which does indeed affect user space applications
> >>> as well as kernels)?
> >>>  
> >>
> >> Are those available on GCC <= 4.2.0 as per PEP 513?
> >>  
> >
> > Pretty sure no manylinux1 compiler is ever going to get these mitigations.
> >
> > For manylinux2010 on x86-64, we can easily use a much newer compiler: RH
> > maintains a recent compiler, currently gcc 7.3, or if that doesn't work for
> > some reason then the conda folks have be apparently figured out how to
> > build the equivalent from gcc upstream releases.
> >  
> 
> Are there different CFLAGS and/or gcc compatibility flags in conda builds
> of Python and C extensions?
> 
> Where are those set in conda builds?
> 
> What's the best way to set CFLAGS in Python builds and C extensions?
> 
> export CFLAGS="-mindirect-branch=thunk -mindirect-branch-register"
> ./configure
> make
> 
> ?
> 
> Why are we supposed to use an old version of GCC that doesn't have the
> retpoline patches that only mitigate Spectre variant 2?
> 
> 
> >
> > Unfortunately, the manylinux2010 infrastructure is not quite ready... I'm
> > pretty sure it needs some volunteers to push it to the finish line, though
> > unfortunately I haven't had enough time to keep track.
> >  
> 
> "PEP 571 -- The manylinux2010 Platform Tag"
> https://www.python.org/dev/peps/pep-0571/
> 
> "Tracking issue for manylinux2010 rollout"
> https://github.com/pypa/manylinux/issues/179
> 
> Are all current Python builds and C extensions vulnerable to Spectre
> variants {1, 2, *}?
> 
> >  
>