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

Wes Turner wes.turner at gmail.com
Fri Sep 21 03:11:59 EDT 2018

I feel like you are actively undermining attempts to prevent exploitation
of known vulnerabilities because the software in question is currently too

For a 4-8% performance penalty, we could just add the CFLAGS to the build
now and not worry about it.

I give up.

On Friday, September 21, 2018, Franklin? Lee <leewangzhong+python at gmail.com>

> On Thu, Sep 20, 2018 at 2:10 PM Wes Turner <wes.turner at gmail.com> wrote:
> >
> > On Thursday, September 20, 2018, Stefan Ring <stefanrin at gmail.com>
> wrote:
> >>
> >> On Tue, Sep 18, 2018 at 8:38 AM INADA Naoki <songofacandy at gmail.com>
> wrote:
> >>
> >> > I think this topic should split to two topics: (1) Guard Python
> >> > process from Spectre/Meltdown
> >> > attack from other process, (2) Prohibit Python code attack other
> >> > processes by using
> >> > Spectre/Meltdown.
> >>
> >> (3) Guard Python from performance degradation by overly aggressive
> >> Spectre "mitigation".
> >
> >
> > > Spectre has the potential of having a greater impact on cloud
> providers than Meltdown. Whereas Meltdown allows unauthorized applications
> to read from privileged memory to obtain sensitive data from processes
> running on the same cloud server, Spectre can allow malicious programs to
> induce a hypervisor to transmit the data to a guest system running on top
> of it.
> > - Private SSL certs
> > - Cached keys and passwords in non-zeroed RAM
> > - [...]
> >
> > https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
> It's true that the attacks should worry cloud providers. Doesn't that
> mean that companies like Amazon, Microsoft (Steve), and Docker should
> have done analyses on CPython's vulnerability to these exploits?
> Has/should/can anyone officially representing Python contact the
> companies and ask them?
> When I followed your quote to find the context, I found it uses, as
> its source, a Forbes article. The source cited by THAT article is
> Daniel Gruss, who was one of the researchers. Should someone from the
> PSF contact the researchers? Steve says he spoke to some of them to
> judge whether the proposed compiler flags would help, and decided
> against it.
> Absent of expert input, here's my non-expert take: That quote requires
> an OS-level fix. A Python program without the proper permissions can't
> do such things unless there is a vulnerability with the OS, and it is
> extremely unlikely for anyone to update Python for Spectre but not
> update the OS (and they'd be screwed in any case). And even if there
> is a vulnerability in the OS, maybe the way to exploit it is by using
> arbitrary Python execution (which you need before you can TRY to use
> Spectre) on this Python interpreter. You can then write a new binary
> file and run THAT, and it will be fast enough. That's not something
> you can fix about CPython.
> Also, (again with my understanding) the problem of Spectre and
> Meltdown are that you can escape sandboxes and the like, such as the
> user/kernel divide, or a software sandbox like that provided by a
> JavaScript VM. For CPython to be "vulnerable" to these attacks, it
> needs to have some kind of sandbox or protection to break out of.
> Instead, we sometimes have sandboxes AROUND CPython (like Jupyter) or
> WITHIN CPython. I don't see how it makes sense to talk about a sandbox
> escape FOR CPython (yet).
> Your original post linked to a discussion about Linux using those
> build flags. Linux is a kernel, and has such protections that can be
> bypassed, so it has something to worry about. Malicious code can be
> native code, which (to my understanding) will be fast enough to
> exploit the cache miss time. Here's Google's article about the
> retpoline and why it helps:
> https://support.google.com/faqs/answer/7625886
> As of yet, you have quoted passages that have little relevance to
> interpreter devs, especially non-JIT interpreters, and you have linked
> to entire articles for non-experts with little relevance to
> interpreter devs. This doesn't show that you have any better of an
> understanding than I have, which is less than the understanding that
> some of the Python devs have, and much less than what Steve has. In
> short, it LOOKS like you don't know what you're talking about. If you
> have a different and deeper understanding of the problem, then you
> need to show it, and say why there is a problem for CPython
> specifically. Or find someone who can do that for you.
> > Here's one:
> > https://github.com/Eugnis/spectre-attack/blob/master/Source.c
> >
> > Is this too slow in CPython with:
> > - Coroutines (asyncio (tulip))
> > - PyPy JIT *
> > - Numba JIT *
> > - C Extensions *
> > - Cython *
> >
> > * Not anyone here's problem.
> C extensions are obviously fast enough. I think most of the other
> starred examples are fast enough, but it's probably more subtle than I
> think and requires further analysis by their devs. I also think
> there's something important I'm still missing about what's required
> and what it can do.
> I don't see what coroutines have to do with it. Coroutines are still
> Python code, and they're subject to the GIL.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180921/f2c19986/attachment-0001.html>

More information about the Python-Dev mailing list