Slashdot Mirror
Google's Project Zero Team Discovered Critical CPU Flaw Last Year (techcrunch.com)
An anonymous reader quotes a report from TechCrunch: In a blog post published minutes ago, Google's Security team announced what they have done to protect Google Cloud customers against the chip vulnerability announced earlier today. They also indicated their Project Zero team discovered this vulnerability last year (although they weren't specific with the timing). The company stated that it informed the chip makers of the issue, which is caused by a process known as "speculative execution." This is an advanced technique that enables the chip to essentially guess what instructions might logically be coming next to speed up execution. Unfortunately, that capability is vulnerable to malicious actors who could access critical information stored in memory, including encryption keys and passwords. According to Google, this affects all chip makers, including those from AMD, ARM and Intel (although AMD has denied they are vulnerable). In a blog post, Intel denied the vulnerability was confined to their chips, as had been reported by some outlets. The Google Security team wrote that they began taking steps to protect Google services from the flaw as soon as they learned about it.
I wonder who else they informed. There is quite a zero-day hole here.
FCKGW 09F9 42
> Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect.
By using the AND statement there, a casual reader might think these not bugs or flaws in their processors. A close logical reading reveals the only reason this statement is accurate is because the second half is presumed "incorrect".
Link to technical details for those that want it: https://security.googleblog.co...
If you aren't running virtual machines then it isn't an issue.
This is more of a server attack and a web host attack.
> ... I wonder who else they informed. There is quite a zero-day hole here ...
Hopefully not the NSA
> ... According to Google, this affects all chip makers, including those from AMD, ARM and Intel
Looks like all the major CPUs are affected
After the Snowden saga, I can't help but suspect NSA is involved, somehow
Intel are in full damage control, but they deserve to lose business after this disaster and ME.
It was well known that on Pentium line cpus, a speculative execution branch can access protected memory, but it will just cause page fault in the end.
The first practical access timing exploit was discovered in 2016. Googlers just found out an even easier way last
What about my Commodore 64?
There are two exploits revealed here: Meltdown and Phantom
Intel, AMD, and some/all ARM chip are vulnerable to at least one of the two Phantom attacks, but patching Phantom will not produce any significant performance reductions.
At this time, only Intel systems have exhibited vulnerability to Metldown. Patching Meltdown comes with serious consequences.
So AMD is basically correct in stating that they are not in the same position as Intel .
Google did not test these vulnerabilities on any Zen based CPUs. They tested only on older processors:
"AMD FX(tm)-8320, AMD PRO A8-9600 R7"
https://googleprojectzero.blog...
This is more of a server attack and a web host attack.
No, it's not specific to web servers.
They do use web servers as an example of where the exploit might be applied, but it's not specific.
Basically, this exploit allows to abuse the way speculative execution is done to leak information out of the kernel space into the user space.
(And there are presentation at the CCC of successful abuses done... in Javascript. In a browser).
For more details :
most modern CISC processors (Intel - except for Atoms and Xeon Phi - AMD, etc.) are pipelined and do out-of-order execution.
Executing a CISC instruction requires several steps (micro-ops) and for performance reasons, they keep several instruction in flight (Once instruction A goes out of step 1 and into step 2, you can try already pushing instruction B into step 1).
To gain even more performance, CPUs try to be clever about this (instruction B actually needs results of instruction A, so it needs to wait. But the next instruction C actually can already be started, it doesn't depend on anything still in the pipeline).
Bordering on crystal ball-clever (the next instruction B is a conditional jump. But it looks like a loop, so there's a high chance that it will jump back and repeat. We might as well start working back on instruction A, in case we are correct about this jump).
That's speculative execution : working in advance on stuff that might not even be needed.
(Sometimes, you end up needing to bail out of your speculation, throw the work away and restart because you got your crystal ball wrong. But it's better than just sitting there waiting).
now about memory :
any modern processor worth its salt has memory protection, meaning it handles access rights : Which process can read-write which virtual addresses ?
Usually, sensitive information in the OS is shielded away from the regular software.
On a modern Linux, you can't crash the whole system by writing junk at the wrong address, like you used to do in the old MS-DOS days.
If your software attempts to read something out of the system, the read attempt will be rejected.
the exploit relies on how these both play together.
It happens to be that, in the case of Intel's processors (but not of AMD's), the step where the memory page is loaded from the DRAM stick into the cache happens before the check if the read is valid.
By the time the Intel CPU does the check and notice that the read is invalid and rejects it, quite a lot has happened.
(Things got loaded into cache, other instructions have started their speculative execution in the pipeline, etc.)
These things are measurable (you can measure the timing of some computation to guess what's in the cache and what's not).
Meaning that it's possible to leak sensitive information, that normally pertain in to the OS and shouldn't be application-accessible, by doing a ton of such speculative-execution and timings.
At CCC there was some presentation of this done in javascript: Technically, your browser right now could be executing some random javascript shit from some shaddy website in one of your background tabs and trying to learn as much from your OS as possible.
Such information could further be used while mounting privilege escalations, or other attacks.
In the specific situation of AMD processors, the check is done much earlier (according to their lklm post) and thus not much else has happened already, and there's not much leak from which you could learn.
I have no idea how ARM64 are affected. (But it might also be the cache getting populated before the read attempts get rejected).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
The vulnerabilities discovered in the Intel CPUs will never be exploited, as the Intel Management Engine already provides all the necessary backdoors.
Doesn't affect AMD64
The horrible leak that gives access of kernel information to any userspace software that was revealed yesterday doesn't affect AMD64 :
AMD processor reject invalid access much earlier in the pipeline and nothing much happens before that point (e.g.: loading into cache) that could be measured by timing, etc.
In the google paper, they are abusing a different set of anomalies were an application end's up reading it's own memory (yay... ). That *could* be affecting AMD64, but :
- it's only an application in user-space accessing it's own in user-space memory.
- by enabling a few non-standard kernel settings, you end up with a situation where you can send eBPF (the bytecode used by modern packet filtering) to a in-kernel JIT, and it's execution will end up with some in-kernel code reading its own in-kernel memory.
The main big difference, the take-home message:
- on Intel CPU, you have a violation of boundary separation : an end-user application could access information leaking out of the kernel.
- on AMD CPU, this does not happen : you only access information on the same side of the separation boundary.
Or in other words :
- On Intel are in deep shit right now. They need a serious circumvention around it. It means context switch - each time a software calls a system call (e.g.: to access the file system) - the OS needs to flush out all the sensitive information to make them unreachable by the exploit. The end result : massive performance hit.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Intel have been very slow in producing new CPUs the past months. This issue (they've known for a year) is likely related to the decreased production.
Slashdot, fix the reply notifications... You won't get away with it...
If you dig into the details :
AMD actually don't violate boundaries.
As in their LKLM post, they do the access rights checks before anything else, and if rejected nothing much happens that can be timed.
Meaning there's no leaking of kernel information into user-space programs.
The only thing that Google successfully demonstrated is :
- leaking some users-space's program own information (yay!...). There's not much boundary violation here.
- using some non-standard linux kernel settings, to send eBPF (the bytecode used by modern packet filtering) to a JIT that will execute it in kernel. You end-up with in-kernel code being able to leak its own in-kernel information. That might give possibility to create some scary constructs, but ISN'T a violation of boundaries (you're already on the other side of the kernel fence) and requires non-standard settings (which basically amount to giving possibility to execute user-supplied (byte-) code in-kernel. So you basically get what you've deserved for inviting users into your kernel)
On the other hands Intel CPUs do violate boundaries :
It does quite a lot before eventually deciding to kill the invalid access.
All this "lot" are things that can be measured afterward, meaning that information from the kernel can be leaked into the user-app.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
(1) There seems to be two separate exploits which you need to dig into the reporting to work. The Register's coverage is quite good and explains it all. "MELTDOWN" seems to be the more problematic one, and affects Intel and ARM chips. "SPECTRE" seems less problematic and affects AMD chips as well.
(2) AMD affected or not? Google says yeah, AMD says nay. However the wording from the LKML list is that "AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against". I think this references that the kernel patch is targeted against MELTDOWN, which does not affect AMD chips (see point 1)
(3) Although everyone's kicking Intel down, the main problem is that no-one can really trust each other now. I know there is a claim of "defective by design", but a lot of things can be described that way if they aren't used in their intended manner. In a "sane" world there would be no malicious actors trying to exploit what seems like quite a clever trick relying on timings (not a chip designer/expert). I read a lot of issues with the web came about, due to the fact that when it was designed everyone on the internet trusted each other, so security against bad apples wasn't designed in. As things have been commercialised you can see the effects, to the point that the only sane way to browse is using ad blockers and no script.
My thoughts on people suing Intel are a bit conflicted. Probably based on US law they would lose, but my analogy is like blaming (insert car manufacturer here) for selling you a car which crashes only when someone throws stones at it. We need stronger laws and protections against the rise in hostile actors.
(4) It's interesting that the Google blog post couldn't wait for the embargo-ed deadline of 9th January. They and their customers must have been getting really spooked. I suspect that this was being worked on and known by multiple parties, and a bit of coordination would have been good rather than panic.
(5) It'll be interesting to see what happens with regards to performance - from my understanding the SPECTRE variants just needs code recompilation. Most home workloads should not be affected by the two exploits, however I think if you are I/O heavy then it may be an issues.
Interesting time indeed.
Basically :
AMD checks access rights first and if rejected nothing much happens.
Meaning no leaks from kernel information into user-space running software.
- Google only demonstrated a in user-space software accessing its own in user-space info.
- And by using some non standard settings, it's possible to give bytecode to that kernel, and that piece of in-kernel software will access its own in-kernel info. (But you're already on the other side of the kernel fence)
Nothing gets accross the kernel fence.
Intel checks access rights much later on. By that time quite a lot has happened (e.g.: things could have been loaded in the cache, etc.). By measuring those things, you can deduce information that you should not have access to.
It means that a user-space software could end up getting sensitive information that normally should stay in-kernel.
These subtle timings of cache enable you to get information accross the kernel fence into user-land.
To mitigate these, each time a user-land software calls into a kernel function (e.g.: filesystem access), the OS needs to flush all it's space from the accessible space. This comes at a big performance cost.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
All the patches just introduce mitigating measures that make exploiting the bug difficult or impossible, but the bug itself can't be patched. Unprivileged code on Intel CPUs can read mapped privileged memory (i.e. kernel memory), full stop. There is no way to fix that. The patch just unmaps almost all kernel memory every time the kernel passes control to unprivileged code.
What about my Commodore 64?
In all seriousness :
- old, in-order, non-pipelined CPU like the 6502 in your good old trusted C64 don't do speculative execution and thus aren't affected specifically by such exploits.
but:
- your 6502 doesn't do any form of memory protection : any piece of software can access any part of the whole system (because poking weird memory location is how you control the hardware on such old system) so any software has full access to anything.
So you C64 is leaking sensitive information.
(Later 68k motorola CPU (68030 and up) eventually started to include an built-in MMU to protect memory access, and thus later Amiga machine featuring them (A2500/30, A3000) can be made imune to OS information leaking into userland. That would the first Comodore hardware - vaguely remote cousin of your C64 - to do so)
Yup, i'm giving a technical answer to a joke.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
There are three different attacks in the blog post by Google's Security team. The first one, for example, works as follows: it loads from a kernel memory address; this will generate an exception, but before the exception is generated (because the page permission check is delayed to improve performance) the subsequent instructions are executed speculatively. None of the following instructions will ever commit, but they can have a noticeable impact on the processor state, as follows: they speculatively execute a load, based on the contents of the position loaded from the kernel space. The load is issued (but not committed), what caches a given memory location. The specific location is based on one bit of the .
When the first load is detected to be illegal, the instructions in the pipeline are flushed, but (the following is the critical part) the cached address remains in L1. By timing a memory access to the corresponding address, they can infer one bit of the given kernel memory. By repeating this, they can subsequently infer the whole word, one bit at a time.
How can they solve this issue? I can only foresee two alternatives:
- Perform permission checks earlier in the pipeline, but this requires modifying the processor microarchitecture. AMD cores are not affected by this attack, so their uarch probably checks permissions before issuing the load.
- Completely or partially flush the contents of the cache after a processor miss-speculation. This is probably the solution being implemented in the patches being developed.
Note that miss-speculations are VERY frequent, since most of the execution of Out-of-Order processors is speculative to improve performance. This explains the VERY significant performance penalties caused by the patches.
Branch Target Injection: Differences in AMD architecture mean there is a near zero risk of exploitation of this variant. Vulnerability to Variant 2 has not been demonstrated on AMD processors to date.
Near zero implies that it is possible! What are the differences, and why do they make it unlikely? could enhancements to the attack make it feasible?
It has also come to light that Intel CEO sold $24M in stock when he was aware of the issue.
http://www.businessinsider.com...
On a long enough timeline, the survival rate for everyone drops to zero.
If I'm reading this correctly, older Intel Atoms are safe because they are in-order CPUs ( https://spectreattack.com/#faq). I still have an Atom from 2010, and it's already slow enough so I'd rather leave it without KPTI. Of course, my important servers are all AMD.
...and same for Xeon Phi.
(Which are basically the same kind of in order approach like Atoms, but linked together with a ginormous SIMD unit - the AVX512 - some kind of ultra-SSE/AVX on steroids that border onto GPU territory. That shouldn't be a surprise, as Xeon Phi are basically what Intel salvaged out of their failed Larrabee GPU experiments).
According to the Wikipedia article about Atom architecture, there's only one single micro-ops ever in flight from a given process (though they DO hyperthreading and might fill unused slot with micro-ops coming from a different thread), and don't do any speculative execution at all :
At no time can you reach a situation were some check (e.g.: a software "rust-style" boundary check, like in the bug also affecting AMD too, or the MMU enforcing memory protection as the bug affecting Intels only) hasn't completed yet, but the invalid read has already started entering the pipeline.
You cannot leak stuff using speculative execution on a CPU that lacks any form of speculative execution, indeed.
(So if the rushed correction enables kpti on your setup, you can safely disable it by giving "nokpti" to it).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Leaking a user space program's own information can be a serious risk especially if that program can also execute arbitary code.
Yes, but although the fact that checks (e.g.: array limit checks done in software) don't work perfectly is a problem per se, the fact that YOU ARE RUNNING ARBITRARY CODE in the first place is the main problem here.
In other words, using rust is a nice thing, but it doesn't stop you from writing stupid code in the first place.
(to play with all the usual "rust-troll" that come screaming for out-of-bound checks whenever there's memory overflow exploit mentioned)
A web browser is an example of such code. They have done a proof-of-concept where Javascript running on Chrome can leak information to a remote attacker information within Chrome's memory space. This could include sensitive information such as authentication tokens, private keys, the content of Chrome's password manager, etc.
This is the main reasons why there's been efforts in trying to separate things into isolated processes.
Chrome is using separate process tabs.
Back in the old XUL days, Firefox was using a separate process for Flash (a.k.a.: exploits fire hose).
Now with the big XUL-to-webextension, Mozilla can even turn on electrolysis in Firefox and join the "separate process" bandwagon.
No matter of checks, etc. will be enough in browsers.
- You need to keep the sensitive information and the abitrary remotely-provided code in separate process. (A javascript running while you browse Facebook can logically access your FB token/cookie, but should in no way read the rest of your password manager's content).
- You need to keep the amount of remotely-provided arbitrary code as low as possible (ideally, using a white-listing pluging like the NoScript web extension).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Presumably there is some other patch on the way to fix spectre.
And according the cited article, the mitigation to fix spectre is much less costly.
Also Spectre exploits only basically works around things like array-boundary checks.
i.e.: the check that controls if you're not reading past out-of-bound memory might not have finished yet, and the actual invalid read might have entered the pipeline.
Basically, it's a slap in the face of all "rust-trolls" who are touting array limits check, whenever there's a buffer overflow exploit mentioned.
Using bound checking doesn't excuses you from writing stupid code (here: allowing arbitrary code in the same context as some sensitive data. In Google's demo : enabling some non-standard kernel options that enable abitrary user supplied JITed byte-code in the kernel space)
But basically an application, under spectre, is only accessing memory that it should have accessed anyway.
The trouble starts only when the application does some check to avoid reading some of its memory, but the attacker has a way to send a complicated construct that speculatively execute stuff based on that checked location.
It might be exploitable in some situations (e.g.: running JIT-ed eBPF in-kernel, a javscript running in the same browser process as where the password manager stores its data), but although it's unfortunate that checks don't work, the main problem in these case is the over-all design
(What the fuck is user-supplied bytecode doing in-kernel ? Why should remotely provided javascript and password manager execute in the same context ? etc.)
In these cases Spectre is just *one* way to exfiltrate the data. But by the end of the current year, there's sure to be a couple of other completely different methods that will show up in those badly-designed pieces of software to exfiltrare the same process-accessible sensitive data.
The other Spectre vulnerability and the meltdown don't affect Zen. Meltdown is the vulnerability that needs the KPTI patch.
And Meltdown is the extremely scary stuff.
With it, all the guarantee that normal memory protection gives you fly out of the window.
You might as well set your MMU on fire.
All hell breaks lose.
It's the proverbial cats and dogs sleeping together mass hysteria.
And the mitigation comes at a big cost :
each time a process calls a system call (e.g.: filesystem to read a file), the kernel needs to flush itself out of the accessible memory space.
According to Intel it might be noticeable to the average user (basically people who only use their laptop to surf the web and whose cpu rarely go above 40%), but realistic benchmarks have shown important slowdowns (so gamers are going to be pissed).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
The flushing it self is time consuming.
The thing is, once flushed, there's no address that the exploited user-land software can attempt to read to guess stuff based on timings.
The memory-protection-violating speculative access still could happen, but there's no sensitive address at which you could send it.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
The concern is that we have a whole new class of attack, exploiting a fundamental feature of the architecture of all modern CPUs. Yes, AMD is less vulnerable to the attacks so far devised, but that is an accident. AMD didn't design to protect against this class of attack, because they didn't know about it.
Maybe the attacks are tiny bit interesting because they abuse the speculative execution.
(CPU starting to execute stuff before hand, for performance reason).
But there's a big major difference.
In the case of the Meltdown exploit, the stuff that affect Intel-only CPU, the whole guarantee that memory protection gave don't hold anymore.
The MMU is made completely irrelevant.
It entirely breaks whole concepts of computer security.
You might as well go back to MS-DOS era / pre-68030 era, when any piece of code could read/write any arbitrary memory location without any restriction.
It's BIG.
Intel has made a bit of a gamble : for speed purpose, it's a bit faster to postpone the check a little bit further down the pipeline.
AMD has made a conscious security choice : check rights as soon as possible, because that's what is the most security sensible stuff to do, even if it means taking a tiny performance hit because you need to make more checks on more potential branches. It's more correct this way.
AMD hasn't specifically planned the Meltdown exploit ahead of time, but they have taken the formally correct way to handle security, and it has payed in the long term (the CPU didn't end up affected once Meltdown was discovered) even if it did take a small performance hit in the short term (didn't benefit from the tiny performance increase that Intel did).
Again, due to Meltdown exploit Intel has broken fundamental tenet of memory protection. (Which just happened to not have been made clearly visible until recently, because nobody though about this specific timing exploit. But this has been "at risk" since the first Pentiums whose speculative execution was allow to go past security checks).
The Spectre exploits, of which one is also affecting AMD CPUs is in an entirely different league.
Whereas Meltdown on Intel CPUs goes across limits that should have been held by memory protection,
nothing in Spectre exploit is accessing something that the exploited application didn't have already access to.
It's simply a way for getting around some checks that might be in the way.
i.e.: that application might be making checks to array boundaries, before accessing them.
Due to speculative execution, the check that controls if we're not accessing out of bound might not have finished yet, and yet the actual invalid read might be in the pipeline already.
I doesn't give you sudden access to things that you shouldn't have access to. It just gives a way around some type of safety checks that might exist in the code you're trying to abuse.
It's a bit exotic and has some air of novelty, because it uses the speculative execution of modern CPU for a change.
But fundamentally it's a timing side-channel, not much different than other timing attacks done for quite some time (even remotely), hence the big work against data-dependent jumps in cryptography code.
And although it does open a couple of opportunity, the big deal isn't that much in the exploit itself.
Mostly, it's a big slap in the face of all "rust-troll" who come trumpeting for array limits checks whenever there's a buffer overflow exploit:
Memory access check should lift any responsibility from writing stupid code.
Yes, to bad that some of the checks can be slightly by passed, but:
- Why the fuck are you enabling non-standard kernel option to enable user-supplied JITed byte-code in the kernel ? User-supplied stuff in-kernel, what could possibly go wrong ?
- Is keeping sensitive stuff, like the storage of the password manager, and dangerous stuff, like execution remotely-provided javascript, in the same process a reasonable stuff to do ?
The k
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
The problem is, due to the Unix architecture, a lot of the GPU system lives in the kernelspace while still executing userspace code, and a process can thus straddle both.
Yeah, but actually... Nope. Not at all.
The only tiny bit that is running in kernel is the driver that receives the command stream and passes it to the actual physical GFX hardware for rendering.
That's the DRM module, the tiny stuff with ".ko" at the end ("amdgpu.ko", etc.)
Everything else in the rendering stack is handled by libraries (mesa's "libGL.so", "libdrm.so" and its hardware specific variants). All these libraries are in charge of handling all the simpler and nicer language and API that your software uses and converting them into the stream of low-level instruction that needs to be passed to the rendering hardware.
The only point where you can provide arbitrary code, is shaders. As in pixel/geometry/etc. :
Even if you abuse the GPGPU interface to send specitally crafted bytecode (that doesn't even map valid GSL / CL code)
you're pretty much limited.
There are only two situation :
- There's an actual GPU in the machine (not necessarily a discrete one) : the whole stack (which again runs in your context anyway) never executes anything, it only manipulates the bytecode you've given to convert it into commands that the hardware understands. If the API used happens to be Vulkan, as opposed to OpenGL - this might even happen in several threads, but still in your process contexts, no juicy bits to access.
Once ready, this low-level stuff leaves your process and eventually get sent to your hardware. The only bit of software running in the kernel mode is the one in charged of channeling this data to the actual hardware. It doesn't execute it, it only moves data around. For all it knows, this might not even be valid executable code.
In short, if there's GPU hardware, the only bit of stuff that get executed in kernel mode is a tiny fixed routine that is in charge with sending you code to the hardware for rendering. None of the user-supplied stuff is ever executed in the CPU at all.
- There's no actual GPU, graphics are 100% done in software (e.g.: you use LLVMpipe mesa driver). In which case the user supplied code is gathered, compiled into CPU binary code, and executed. All this happens from within your process' context, being executed with the same context (but in multiple thread). At no point in time could the sharder code ever see anything that the process doesn't see already. At not point is any user-supplied code ever executed in kernel mode. The only kernel mode stuff that is ever going to be executed anyway is some unrelated frame-buffer handling stuff (At some point in time the window composer is going to take the buffer into which your application was rendering, and paint it on the screen. At which point some kernel code is going to jump in to map the framebuffer into the address space of the composer).
That's not to say that running arbitrary GPGPU code is safe. It's not :
- older GPU don't have their own MMUs, so any shader could be trying to get data from any arbitrary graphic buffer. A WebGL javascript could be trying to snapshot your banking app window buffer. (more modern GPU are starting to feature their own MMU)
- some consumer-level CPUs from Intel don't have a IOMMU : the GPU could be trying to read from any random location of the DRAM sticks unrestrained.
But at no moment is any of the code provided by the user gettint executed with a kernel context.
On Windows, due to the GPU drivers being usermode, that's mitigated somewhat, but still not entirely safe.
Windows GPU drivers being usermode has nothing to do with arbitrary user code getting executed in the kernel mode.
It's just a safety mechanism, where the 100% of the blob shit that the no-name manufacturer of your graphic card has provided is executed as a user-land app, and none of it getting executed in kernel context.
Think
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
So, five days ago?
Have gnu, will travel.
I'm going back to my PowerMac G5 Tower, suckit x86!
I've been wondering if the idea of core should be taken further in it basically being independent processors (kind of like GPUs). Your OS will run independently communicating across an internal bus.
You may laugh, but if Intel thought it would save this mess they would use.
This seems at first glance to be a non-issue... until you consider that lots of processes -- like your web browser -- run JITed code from untrusted sources.
As I've mentionned in the end of my long rant, here the main problem isn't that this peculiar flaw enables the process to inspect its own data.
The main problem is the actually stupid design of putting sensitive data and remotely-provided arbitrary code in the same security container.
Spectre is just one possible attack in this context. By the end of 2018, there's surely going to be another exploit that could hose the same browser.
The stupid mainly comes from the way browser are designed (or in Google's demo, the way somebody would enable the in kernel user-supplied JIT-ed bytecode).
With Chrome you can optionally enable strict site isolation which will run the content from every origin in a different process, but that comes at a performance cost.
But should be done by default (as the TOR browser does, apparently, given the other ansers). To bad there's some hit, but that's the safest way to handle stuff.
This should be the automatic way to go : keep sensitive stuff appart.
Today it might be a Spectre attack on an AMD CPU, and tomorrow it might be yet a different exploit affecting the Javascript engine or some other component of your browser.
Whining about Spectre affecting the AMD CPUs is just diverting attention from the very bad over all design of keeping sensitive stuff there.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
mostly mean that writing a JIT compiler for untrusted code is actually much, much harder than the people writing them thought.
Well, though you'll have to conceed that they didn't make any fundamental flaw in the actual JIT implementation - this time.
It's on the much larger scale of design flaw of putting a JIT running externally supplied arbitrary code in the same context. Something bad is going to happen eventally.
Today it might be more exploiting some weird CPU behaviour,
tomorrow it might be exploiting a straight flaw in the JIT compiler.
Still putting both in the same place was a bad idea. Something was going to happen no matter what. Spectre happens to be the first one exploiting it.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
That breaks LastPass and Yubikeys.
That's 5 days ago.
how do you get a pointer to kernel memory in JS without needing to break the virtual machine?
var *p = (char *)0xdeadbeef;
Answering the "how to do random memory access in a language without pointers" part of the question: by abusing arrays and boundary checks (link to a Spectre abuse) (Note that it's a Spectre abuse, not a Meltdown abuse. For the meltdown I'll have to track the CCC link).
If a piece of javascript is using the ASM.js specific sub-dialect, it will be JITed to actual x86-64 machine code (in the example each statement of the javascript is translated into one or two machine code instructions).
If you carefully craft you code, the produced code is still entirely valid, but the actual memory accessing functions aren't to far away.
As said, the code is valid, if you mentally trace through it :
- if the provided index is within bound of the "simpleByte" array, the rest of the step will get executed (including the write, which is forced to stay within bounds of the target "probe" array).
- if the provided index is out-of-bound, the conditional will be false, and the conditional jump will skip the entire block, nothing bad happens.
But when executed on a deeply pipelined CPU that does speculative execution :
- before the condition has finished getting executed (it takes some time: it needs to read the value of the lenght from memory, compare it with index, and only then do the jump), the CPU will try to feed instructions in the pipeline.
- its best guess is that the execution will run through (based on some predictors: e.g. code jumping backward is usually loops and is likely to be taken most of the time (except on the last iteration), code jumping forward is usually error checks and usually not jumping - error happening less often than normal execution. That's a real-world heuristic used in some processors).
- so it begins preparing the next instruction, and the instructions afterward.
- by the time that the "if" condition finished (the compare and conditional jump are executed), the rest of the instructions might be well into the pipeline
- that means that the memory page of the target "probe" array might already have been moved into the cache, to be ready to be written if the condition was actually correct.
So even if you call this function with a too-big index, even if the CPU throws away all the work it has done wrongly due to erroneous speculation ("probe" array will never actually get written to), there are still some measurable effect ( "probe" array will be in the cache, even if nothing ended up being written to it).
So, if you call this function with beyond-boundary index, you'll end up with a situation where nothing is written to "probe" BUT the specific page (which depends on the content of the out-of-bound location) were "probe" would have been written ends up being stored into cache.
If you use a stupidly big enough index, you might end up accessing something which is way beyond the limit of what the javascript code is supposed to access.
So in short, even if you don't have pointers to read at an arbitrary address, you can ask javascript to read an arbitrary point way beyond the end of an array, and even if there's a boundary check (here explicit in the javascript example), due to speculative execution the CPU will attempt to peek at that arbitrary point anyway.
Now if you repeat this read a lot, and then try to time in turn which part of "probe" is more often faster to read from (because it was already loaded into cache by the previous function), you can guess what that arbitrary point of memory contained.
(i.e.: you choose a random index "0xdeadbeef".
Then 10000 in a row, you call the function with the invalid index and then read "probe[0]", you time it and get XX ms.
Then run it again 10000 in a row, but this time read "probe[4096]". You time it and get YY ms, rought in
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Yes, the tiny DRM bit, that {... long list skipped ..}
None of which executes arbitrary code provided by the end-user, which was the entire point of the discussion.
All the long list you give are fixed functions that the DRM performs when called.
When given arbitrary code, none of it gets executed in kernel space. The kernel code only performs the task of pushing that code to the GPU for execution, it doesn't execute anything itself.
(Also, compared to the actual Mesa userland, the DRM bit *is* small, even the parts which are not concerned by the execution of arbitrary code).
Also, with CUDA, some OpenCL implementations, and some Vulkan implementations, you can build Compute Kernels that run both on GPU and CPU.
And which all run in user space (which is specially important, since CUDA allows arbitrary pointer arithmetics, and you CAN actually write code that does invalid access. Even on the GPU).
None of this kernel will ever get executed while in kernel mode. They all get executed in the context of your application (thought it might be in many background threads).
and just handwaving it away by immediately assuming that everything is safe because "drm is just a tiny little bit" is inane.
I'm not assuming that every thing is safe, I've patiently shown that DRM only plays a an extremely tiny role in regards of user-supplied code, none of which concern *running* the user code.
So the whole "Linux sucks because there's a (much smaller than the user-land libs) part that runs in-kernel" isn't relevant here.
The parts that run in-kernel concern a reduced amount of function, none of which executes arbitrary code.
The user-supplied arbitrary code (shaders, kernels, etc.) is executed either by the GPU, or in the user-land mode of the calling process (but not necessarily the main thread).
The fact that a small subset of the drivers lives in kernel space on line, doesn't directly lead to any of the arbitrary user-supplied code getting executed in-kernel as part of the normal way things work.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Intel SGX is supposed to provide cryptographic isolation of memory .. but does this vulnerability defeat that too?