I feel like you are actively undermining attempts to prevent exploitation of known vulnerabilities because the software in question is currently too slow.
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+pyt...@gmail.com> wrote: > On Thu, Sep 20, 2018 at 2:10 PM Wes Turner <wes.tur...@gmail.com> wrote: > > > > On Thursday, September 20, 2018, Stefan Ring <stefan...@gmail.com> > wrote: > >> > >> On Tue, Sep 18, 2018 at 8:38 AM INADA Naoki <songofaca...@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. >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
