Re: [Python-Dev] SEC: Spectre variant 2: GCC: -mindirect-branch=thunk -mindirect-branch-register
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/4B... - 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@pobox.com> wrote:
On Wed, Sep 12, 2018, 12:29 Joni Orponen <j.orponen@4teamwork.ch> wrote:
On Wed, Sep 12, 2018 at 8:48 PM Wes Turner <wes.turner@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, *}?
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@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/4B... - 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@pobox.com> wrote:
On Wed, Sep 12, 2018, 12:29 Joni Orponen <j.orponen@4teamwork.ch> wrote:
On Wed, Sep 12, 2018 at 8:48 PM Wes Turner <wes.turner@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, *}?
participants (2)
-
Antoine Pitrou -
Wes Turner