echo 2 > /sys/kernel/debug/x86/ibrs_enabled (Coss-posting to distutils-sig, as C extensions may be the most likely abuse vector)
# Forwarded message From: Wes Turner <wes.tur...@gmail.com> Date: Mon, Sep 17, 2018 at 3:41 PM Subject: Re: SEC: Spectre variant 2: GCC: -mindirect-branch=thunk -mindirect-branch-register Cc: Python-Dev <python-...@python.org> On Mon, Sep 17, 2018 at 2:58 PM Wes Turner <wes.tur...@gmail.com> wrote: I thought I read that RH has a kernel flag for userspace? "Controlling the Performance Impact of Microcode and Security Patches for CVE-2017-5754 CVE-2017-5715 and CVE-2017-5753 using Red Hat Enterprise Linux Tunables" https://access.redhat.com/articles/3311301 > Indirect Branch Restricted Speculation (ibrs) > [...] When ibrs_enabled is set to 1 (spectre_v2=ibrs) the kernel runs with indirect branch restricted speculation, which protects the kernel space from attacks (even from hyperthreading/simultaneous multi-threading attacks). When IBRS is set to 2 (spectre_v2=ibrs_always), both userland and kernel runs with indirect branch restricted speculation. This protects userspace from hyperthreading/simultaneous multi-threading attacks as well, and is also the default on certain old AMD processors (family 10h, 12h and 16h). This feature addresses CVE-2017-5715, variant #2. > [...] > echo 2 > /sys/kernel/debug/x86/ibrs_enabled https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown/MitigationControls > echo 2 > /proc/sys/kernel/ibrs_enabled will turn on IBRS in both userspace and kernel ... On Mon, Sep 17, 2018 at 5:26 AM Antoine Pitrou <solip...@pitrou.net> wrote: 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. "Speculative Execution Exploit Performance Impacts - Describing the performance impacts to security patches for CVE-2017-5754 CVE-2017-5753 and CVE-2017-5715" https://access.redhat.com/articles/3307751 - Revised worst-case peformance impact: 4-8% On Sun, Sep 16, 2018 at 8:29 PM Wes Turner <wes.tur...@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 <n...@pobox.com> wrote: > >> On Wed, Sep 12, 2018, 12:29 Joni Orponen <j.orpo...@4teamwork.ch> wrote: >> >>> On Wed, Sep 12, 2018 at 8:48 PM Wes Turner <wes.tur...@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, *}? > >>
-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/ZAJQCMOPD3NFVUGG4MFVIY34C3HP45SF/
