Spectre is basically a big slap in the face of all the "rust-trolls" that come out screaming for array boundary checks whenever there's a buffer overflow happening.
Speculative execution is going to start processing the instruction past the boundary check and some measurable things like loading pages into cache are going to happen anyway, even if the CPU decides to throw away any computation because it realises that the check fails and any subsequent writes dependent on it should not get executed.
That's how its exploited with JavaScript, even if that language doesn't even have arbitrary pointers to begin with.
But on the other hand, Spectre doesnt leak any data to which the process didn't have access to begin with.
So it's only useful for a small subset of targets (e.g.: stupid browsers that keep sensitivie data in the same process as where remotely provided Javascript is JITed and executed), where the software counts exclusively on boundary checks to make sure nothing bad happens, but the user can send specially crafted code (Javascript in that example) that will use Spectre to deduce what data lies in the same process beyond the boundary.
Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets.
No. Nope. nononono. not at all.
Spectre relies on speculative execution starting to handle instruction past some software check (ie.: array boundary check and then array access) and some side-effect leaking information (e.g.: loading things into cache). You could only consider these programs as "following best practice" only by interpreting it as "do boundary check to avoid buffer over-runs". Nothing more.
Still it's only leaking information to which the process HAD ACCESS to begin with. Which means that only a tiny subset of programs are susceptible. More precisely the subset of programs which are stupid enough to keep the sensitive data in the same context where arbitrary code get executed.
i.e.: the Google Project Zero worked by turning on a special option in linux that allows user-provided (!) byte-code to get JIT-ed and executed in-kernel, which then in turn obviously has access to in-kernel data.
i.e.: there are affected browsers which keep sensitive data in the same context where they JIT and execute remotely provided Javascript (something which has "what could possibly go wrong" written all over it).
At least on Linux speculative execution cannot be used to access data *across* processes, because each process has its own address space. i.e.: There's no virtual memory address that you can point your CPU to that contain data coming from a different process (unless it was intentionally shared across processes).
On the other hand, each process has the kernel mapped in its address space (though each process might get a different random mapping, thanks to things like KASLR), because it needs to call into it for system call (e.g.: call the filesystem to read a file). That kernel memory is shielded from userland interference by memory protection (the process isn't allowed to read/write in the kernel space). But due to the way Intel CPU specifically handle memory protection (in case of speculative execution, the access rights check is done too late, and some measurable side effects, such as bringing things into cache, might have happened already), on Intel CPU Meltdown manages to get around memory protection and leak kernel stuff into userland.
In fact, the safety checks of said best practices actually increase the attack surface and may make applications more susceptible to Spectre.
Given that Spectre is about things downstream form a safety check being in the pipeline before the check fails, you could say that in a stretch....
Spectre is harder to exploit than Meltdown {..} However, it is possible to prevent specific known exploits based on Spectre through software patches
Well given that Spectre is about leaking stuff to which the process has read-access anyway, it hard to exploit because it requires finding software with the right mix of bad design (mainly sensitive data and arbitrary code execution in the same process). On the other hand, it's possible to just NOT design software in such "what could possibly go wrong ?" way.
but it is also harder to mitigate
Well, given that it's just speculative execution working as it should...
Spectre cannot be considered intentional tampering. It's still speculative execution working as it should. Only now has someone though of a way to exploit its (normal) side-effects.
But it only leaks data to which the process already had access to begin with. Meaning that only a very tiny sub-category of software are affected, mainly software which run arbitrary code in the same context where sensitive data is stored (which is a very bad design flaw).
Google demo relies on a (for a reason) non-standard linux kernel settings, that allows user-provided arbitrary JIT-ed bytecode to be run in-kernel, that can then in turn leak in-kernel data. And there are a few affected browser, that keep sensitive data in the same process where remotely provided Javascript is JITed and executed.
In other words : it's still a CPU working as it should, and only a tiny range of (badly designed) software affected : probably not intentionnal.
----
Meltdown is much more horrible (it's basically memory protection not working as it should. CPU doesn't work any more as supposed).
But given that Intel has done it for some tiny performance improvement (checking access rights late in the instruction pipeline is cheaper than checking it outright in the beginning as all other CPUs are doing), okkam razzor would tend to make us believe that Intel jumped at the opportunity to shave off a tiny bit of performance as they usually do, instead of some dark cloak conspiracy.
I'm not saying that government-sponsored spying doesn't exist, just that there's absolutely zero need to force Intel to jump onto some performance shaving trick that ends up being dangerous.
Technically, Spectre only reveals data to which the process had already access to begin with.
In the Google demo, it works because all in-kernel code (here: JIT-ed bytecode) has access to in-kernel data. There's a reason why the option is non-standard.
In the few affected browser, it works because said browsers were stupid enough to keep sensitive data (passwords ?) in the same process as where remotely provided Javascript code is JITed and executed. (I.e.: stupid design that should be fixed anyway. If not Spectre today, there's sure to be another exploitable flaw discovered before the end of this year which could also be leaking sensitive data. Always keep your sensitive data and arbitrary code execution segregated).
But correctly designed software should be unaffected.
On the other hand, Spectre only leaks information to which the process had access to begin with. The CPU is still working as intended.
It's only badly designed software which as affected (keeping sensitive information in the same context where arbitrary code can be executed. ie.: Browsers that keep password in the same context as where the Javascript is executed, or a special non-standard linux kernel settings that enables an in-kernel JIT engine for the bytecode used by packet filtering - there's an obvious reason why this setting is non-standard !)
But basically Spectre doesn't open new access to restricted data.
Affected software should be fixed any way (i.e.: try to keep JITed arbitrary code away from sensitive data), because if not Spectre today, another different exploit coming this year could end up being just as bad. Sensitive data should just be kept away from arbitrary code execution, no matter what.
---
Whereas with Meltdown it's suddenly memory protection not working anymore as intented on Intel CPUs (they do the access rights too late, way after other side effects had time to happen), it's the CPU which is doing things wrong. AMD isn't affected, because they did things formally correctly - mainly doing the access rights check at the beginning of the pipeline.
It's not that trivial to fix "in the wild": because of meltdown you just can't rely on memory protection anymore (the kernel isn't sage from user-land software anymore), the only possible fix are performance killer (at end of each call, the kernel must flush itself out of the space accessible by the user-land process).
Spectre is not the same thing. Multiple processor bugs were revealed.
Spectre is not a bug. It's not suddenly accessing something which should not be accessed in the first place. It's not breaking memory protection, only giving data that the process can already read.
Speculative execution is still working as it should. It just happens to have a side effect that got noticed now, and got used in timing attacks. (Just like any other timing attack).
But the CPU is still working as intended, it's not a bug.
Only badly designed software that keeps that doesn't properly isolates sensitive data and remotely provided arbitrary code that can be abused (some browser, some non-standard Linux kernel settings that are non-standard for a reason).
---
(This is completely different from Meltdown, where suddenly memory protection doesn't work any more. The process access things it was never supposed to access in the first place).
Meltdown uses out-of-order execution and a side channel attack that is unique to Intel. Spectre uses speculative execution and is more generalized, with tested proof-of-concept attack code on AMD and ARM.
On the other hand, Spectre only enables access to data to which the process had access to begin with. (Meh...) Only a very small subset of software can actually be usefully abused, mostly due to bad software design :
- Google's demo relied on a non standard setting that turns on a JIT engine that runs user-provide arbitrary byte-code in-kernel (common, in-kernel ? What could possibly go wrong ! Seriously, there's a reason why this setting is non-standard).
- There are browser with bad designs that manage to keep sensitive data in the same context as remotely-provided Javascript code. In other words, a problem waiting to happen. Spectre just happens to be the exploit which bit them now, but any other completely different exploit could have come in a couple of months and done similar damage.
Yup, it's bad that speculative execution may lead to some side effect, but it's working as intended. It's the software which is stupid (or dangerous options turned on, as in the kernel) and should be fixed before another problems comes again.
---
Whereas Meltdown is an entire different level of worrying.
On Intel CPU, access rights are checked way to late, by that time speculative execution has had time to do stuff which can also be timed. Other CPU (like AMD's) work much more sanely, doing the check first and not progressing anything. It cost a tiny bit of performance, but is more formally correct and ends up protecting against such problems.
That means that on Intel CPUs the whole set of guarantee that memory protection is supposed to give don't hold true any more. It's the whole memory protection scheme flying out of the window.
On Intel CPUs memory protection has stoped working as it should. The software is correct on relying on memory protection for security, it's Intel's protection that suddenly doesn't work anymore. No matter if you write correct software.
On any other CPU protection works as it should, and non-stupid software is safe.
If the defect is in the microcode and they patch it in software, isn't it still vulnerable?
The defect that is happening, is that (by careful timing of cache) it's possible to see information to which the process has full access anyway.
The stupidity of some browsers is to store sensitive information in the same process as where the remotely provided javascript is JITed and executed, relying on "well, we do array boundary checks before reading them, so we should be safe from buffer overflows" for security.
Spectre works in a few corner cases because there are situation where software has full access to it's own data, but doesn't actually want to access any arbitrary data : mainly, it wants the Javascript to only read the data inside its array, and not outside were some sensitive information would be stored.
Which would fix ? The blunder which gives access to already accessible data ? The stupid software which keeps sensitive data and arbitrary code within reach of each other.
The first only works in a few key cases. The second is a problem waiting to happen. If it's not Spectre today, it might be a completely different exploit tomorrow.
Doesn't seem like it would be difficult to undo or work around the software patch to access the original defective microcode.
The quick'n'dirty software correction would be : - disabled JIT, so the arbirary code doesn't generate a thigh compact group of machine instruction that can all fit inside the CPU pipeline. That's going to be order of magnitude more difficult to circumvent, at the cost of performance hit specific to the formelly JIT-ed code. (But you still have a broken software that is going to get b0rken by the next coming exploit).
The formally correct software correction would be: - keep the sensitive data and arbitrary code separate from each other. Thus even if a different exploit happens to your system, it would still not be able to access the sensitive data. You've fixed the problem forever.
The microcode/CPU correction would be : - completely disable speculative execution, meaning a performance hit whenever there's a conditionnal jump in the code (basically everywhere). You computer now runs like shit, and you still have broken-by-design software sitting waiting for the next exploit.
Side effects are something that is to be expected.
In case of spectre, speculative execution is happening as it shoudl, everything is having the correct behaviour. There's no *formally wrong* behaviour to be patched in the CPU or in microcode. There's nothing that should be patched in the CPU, the CPU works as intended, it just happens that this "as intended" produce a couple of side effects that where not noticed until recently.
It's just that researcher have noticed "yet another thing that can be timed" and thus a new side-channel that can be used to leak information. The only novelty is it's built around a different CPU feature than other timing attacks. It's still your gandpa's classical timing attack, only wearing a new fancy hat.
The main problem is that arbitrary externaly supplied code and sensitive data should never co-exist in the same process in the first place. It's just problems waiting to happen. (Seriously eBPF ? User supplied byte-code JITed in-kernel ? What could possibly go wrong ? there's a reason why that setting is non-standard)
Affected browsers (lots of them !) have basically a flawed design (running JITed Javascript code in the same context as some sensitive information reside). It just happens the spectre was the exploit that happen to reveal the flaw. But basically, it was just a problem waiting to happen.
IT NEEDS to be handled in the software anyway (even if the CPU could suddenly stop doing speculative execution, e.g.: you switch to an Atom processor, there could still be yet another different exploit 2 months down the line that finds another way for Javascript to access all the information that reside in the process. Remove the sensitive data out of the process and you've fixed the software forever, no matter what exploits come here... well as long as the CPU respects memory protection, which is an entirely different level of wrong. Meltdown's level of wrong).
Nope. it only works on microsoft windows. it's only a free bonus for people who have already shelled out money to microsoft. By making people dependent on IE, Microsoft makes sure to increase the sales of Windows.
By making people dependent on Chrome, Google is supposed to profit how ?
and Microsoft (which bailed out Apple).
Which served them in proving that they are not covering 100% of the market of selling operating systems on personal computers. "Look there's also Apple selling OSes ! They are still alive".
Google is selling what again ? Mozilla is selling what ? They aren't covering 100% of sales and profit in a market, they don't sell anything and don't profit there.
Google profits by selling eyeballs =yours (and apps). Their browser (and smartphone) business is entirely accessory.
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.
How could you start an antitrust suit on the grounds of Google Chrome ?
Google Chrome is given away for free (unlike the IE counter example, which was only available to those people who did buy Windows from Microsoft). the source code of most of the parts (all the important one) is available to anyone (so anybody can re-implement a chrome-clone on their system of choice).
Google doesn't make a single penny directly out of Chrome. In fact they don't even need you to use their browser, they just want you to use any browser. Mozilla Firefox could also do the trick (and that's why they are donating money into its development too). Google doesn't give a shit about which browser, as long as you use *A* browser, and go online, where THEN in turn they can earn a ton of money thanks to their very lucrative ads business. But the browser that you chose to actually bring you to these ads is completely irrelevant to their business plan.
The fact that you can one for free from Google (and another one for free by Mozilla, partly paid by Google's money too) is only a bonus. (But a bonus which worth for them to invest into : the more free and easy solutions to go on line, the more eyeballs for them to sell to advertisers).
---
Note that, with a few exceptions (Google is licensing some parts commercially to big manufacturer - mainly the Google Services, and access to Google Play), the same logic also applies to Android (of which a good chunk is available with the source in clear) and which (can be) given away for free (at least AOSP part).
They don't profit from Android (much - there are still the licenses), they profit from people going online (again to be subjected to ads) and coming to pay apps from their Play store.
Internet Explorer back then, locked you into a shit ton of closed source proprietary secret poorly documented stuff (embed OLE objects/ActiveX extensions night mare). There was no sane way to make a web app specifically made for IE to run on anything else except the specific version of IE that it was made for.
Google Chrome mostly relies on open standard. Take another browser that complies with the same open standard, and you can more or less access the same web apps. Chrome's source code is even accessible. When in doubt you can check how they've implemented some non-compliant stuff. In practice, very few web apps run in Chrome but completely fail in Firefox, despite both using entirely different engines.
Yes, a lot of web apps fail in Microsoft Edge/Internet Explorer or in Safari, but has more to do with those being bullshit browser which aren't up to date with standard (microsoft's stuff even more so) than Chrome being a proprietary target.
And then, there's the whole anti-trust / profit angle.
Back during the internet explorer scandals, Microsoft was profitting from selling software. By making sure that as many websites and webapps only work exclusively with IE, Microsoft made sure that people desperately need to buy Windows from them in order to get the bundled in Internet Explorer.
Nowadays, Google doesn't profit at all from Chrome. Their hugest profit driver is matching *results* (though not the search results themselves in Google.com, mind you. But matching ads to serve best to end users. And matching content to keep youtube users hooked while they play ads. etc.) They don't give a shit if you use their browser. They want to use *a* browser, *any* browser, might as well be Firefox if not Chrome (which they *also* finance - Google is pouring money and financing what some could wrongly consider their "main competition"). As long as you end up using this browser to go online, where they can thrown ads at you and sell your eyeballs to the highest bidding advertiser, and where they can monetize the shit out of all the online behaviour data they can gather about you.
Chrome isn't a product on which Google is making money (directly). Chrome is just one of the possible tools that make their actual business (profiting of users going online) possible.
You can hardly suing them for antitrust violations, Chrome is free (i.e.: "gratis" as in beer) as well as major part free software (i.e.: "libre" as in freedom to look into it and build your own browser).
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
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.
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.
What is this penchant so many engineers have for adding needless complexity to (what should be) relatively simple, single-purpose devices? {...} This is now just another thing that can and will go wrong with an already-expensive device, almost certainly shortening its usable lifetime
The 900 series is already making a map of its surrounding as it works (unlike its predecessors, it doesn't random dance. It constantly tracks its exact position using a camera a bit like an upturned mouse). It already records per-position information from its sensors in this map (mostly related to sensors that detect presence of dirt).
It has an always-on wifi antenna, so recording the strength of signal as goes around drawing it's map comes for free.
It's not a needless complexity, it's just about adding 1 line of code to their program and suddenly having a new fun feature.
---
the questions lie more upstream:
- was it really worth adding the mapping feature ? it's a complex power-hungry feature, but in the end of the day, unless you have an extremely weirdly shaped flat (are Escher and Dali your architects ?) the "randomly going aimlessly everywhere until everything is eventually covered" of the predecessors works equally well. The only difference is that now the roomba can stop cleaning, go back straight to the dock to charge, and then resume where it was. So if you want to clean NASA-sized hangars over several charging cycles, it might be worth it...
- was it really worth adding Wifi, so that not only can you use you smartphone as a remote (like the bluetooth enabled 800 series predecessors), or an actual IR or proprietary-ZigBee-like stuff remote like previous models (up to 700), but now thanks to wifi you can also optionnally connect it to the cloud and send it cleaning commands from outside the house ? I doubt there are that many use cases where this is necessary.
Though on the other hand, the security implication are much lower. (It's a cleaning robot. It doesn't have that much processing power. It's doesn't get an actual video stream from the camera, but a list of high-contrast points from the DSP connected to the cam. There isn't much to be gained from those points if a bug accidentally leaks them online. My metaphore of up-turned mouse is apt as a mouse also doesn't send a video feed to the computer)
This will likely turn into another massive violation of people's privacy
I don't know if this is going to open any much more danger than before: - the roomba 900 already make a map of the floor. - the roomba is already connected to your Wifi. Storing the strengh of the connection as the map is built doesn't give much more risks.
And even the current Wifi getting hacked shouldn't disclose too much stuff. (Due to limited computing power budget, the Roomba 900 don't actually "see" only get very precise position from their pseudo-mouse).
Followed soon on by a third thought: - Never buy a Roomba
Actually : never skip doing some research before buying any expensive toy.
In fact: - Nearly all vacuuming robots, including absolutely all of their competitors, and including irobot's roomba 900 series and braava, all make a map of their surrounding (though not all are internet connected). Irobot was simply late at the game (because, as noticed above, it actually doesn't bring much in practice. It just looks less messy to an observer).
- All older roomba (up to 800 serie, and their scooba) (also a few other manufacturer who have sublicensed the design) (as well as no-name asian clones of these) don't do any mapping, they just aimlessly wander around until everything is eventually covered. (But as proven by long-exposure photos, it basically gives the same end result). None of them have any internet connection, only 8
Roomba model comparison chart. Go ahead, you don't have to buy anything. Look. What do you see? The first thing I saw, is that they have multiple models. Gotta admit, I didn't know that.
Check out the bullet points. There are some dubious "features" there, but a couple stand out, almost as negative things where you might think "WTF, some Roombas can't do that?"{...} The multi-room cleaning "feature" shocked me too. Does that mean with the cheaper Roombas, you have to get one for every room? Fuck that.
Well most of the things on this list are exactly that : stupid arbitrary checkbox points, nothing more.
Basically cheaper roomba have smaller batteries than more expensive one (so they can only clean for a shorter amount of time until they need to dock back for charging). But that's about the main difference.
Newer roomba (since the 800) have a bit better roller which might get a little bit less mess, but not by much. But they still sell the olders because they still have them in their warehouse and they are cheap now that they try to get rid of them.
The 900 serie is completely different, in that it uses a camera to track its exact position (think a turned-up optical mouse). So it doesn't randomly dance everywhere until it has covered eventually the whole floor, instead it makes neat orderly grid zig-zags. But unless you have an extremely weirdly shaped flat, it doesn't matter much, both methods will cover everything eventually, one just looks a tiny bit more oderly from the outside.
That means all robot can clean multiple rooms, the battery run time is the only limiting factor. (The 900 being the small exception : as it knows it position it can return to dock, charge, and resume cleaning. It can thus clean a surface much larger than what could be done on a single charge. So if you planned to clean a giant aerospatial hangar, you might need one).
etc.
It's about upselling. I think that's 100% of it. But maybe we all have different buttons to press, and what gets me to think "I have to get a Roomba 960 or else there's no point in getting any Roomba at all" is different from what might make you decide to get a 960 or none at all.;-)
Yup. It's a huge marketing bullshit to make the more expensive look more desirable.
But let's say your spouse wants one, and it's decided: you're getting something. Maybe another stupid fucking bullet point would push your button.
Or you know, maybe like whenever buying any expensive gadget, you read some review, or even better, ask friends who have one for advice. And then realize that maybe the cheap one actually does the job for you.
If that device would make an internal map of it's cleaning thoroughness, i. e. how often it covers an area, that may be useful for trusting this thing
Actually, that the whole purpose of Roomba 900 series (and Braava) : they are able to know their exact position, and thus can draw a nice map of where and how often they've been.
(But in the end, they actually aren't that much more efficient that their "random dance" predecessors)
Making a map of wifi signal basically comes free for a device that already automatically maps its surroundings and has an always-on wifi antenna.
Roomba 900 are mapping robots (unlike their predecessors). They don't do random dance. They know their exact position in the map and are bit more orderly in their path.
So, instead of a poopocalypse, you're look in forward, for a very meticulous precise and neat poop grid zig-zaging across your floor.
The by-now-4-yo kid will smell like poop when walking to your room all the same.
Roomba, all the way up to the 8xx serie (and Scoobas, btw), still do "random dance around". They aimlessly go in any random direction, bump into things, etc. eventually, they'll end up covering the whole surface by the end of the program. At no moment do they have any idea where they are. They just notice the dock when they happen to come by in front of it during the random dance.
(Also they don't have any Wifi. They either have some weird custom proprietary of ZigBee (up to 700 series) to communicate with the non-IR remote and with automatic lightwalls, or have Bluetooth (800 series) to communicate with your smartphone)
In case of cat throw-ups, they'll still enjoy making abstract art in your living room, with the occasional spiral shape thrown in for good looks.
Roomba starting with the 9xx serie (and Braava) having mapping capabilities (older Braava detect a set of IR laser points projected on the ceiling by a special "Northstar" navigation cube. Newer hardware has a webcam, and a DSP that extracts a set of "high contrast points"). The roomba exactly knows where it is at any moment of time and thus can build a map of the place. Because it has an exact known position and a rough map, it doesn't wander aimlessly, but does precise S lines accross the floor. (It also covers everything eventually, end up being measurably the same performance as the random work, but looks a little bit better from the outside). Because of the same, it's also able to directly head for the dock when needed, and can resume cleaning where it left once charged. It also comes with Wifi for communicating with the smartphone (and optionally the cloud).
In case of cat throw up, it will very meticulously spead it in straight zig-zaging line across your floor, eventually building a nice grid.
So which cat trow up artwork you like (abstract vs meticulous grid) depends on your taste, but your dog will still enjoy licking it all the same.
(More seriously: The reason they can do wifi maps before perfecting the cleaning is simply because the maps come for free for a device that already has mapping technology plus an always on wifi antenna).
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.
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 ?
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).
Slashdot Mirror
Yup exactly.
Spectre is basically a big slap in the face of all the "rust-trolls" that come out screaming for array boundary checks whenever there's a buffer overflow happening.
Speculative execution is going to start processing the instruction past the boundary check and some measurable things like loading pages into cache are going to happen anyway, even if the CPU decides to throw away any computation because it realises that the check fails and any subsequent writes dependent on it should not get executed.
That's how its exploited with JavaScript, even if that language doesn't even have arbitrary pointers to begin with.
But on the other hand, Spectre doesnt leak any data to which the process didn't have access to begin with.
So it's only useful for a small subset of targets (e.g.: stupid browsers that keep sensitivie data in the same process as where remotely provided Javascript is JITed and executed), where the software counts exclusively on boundary checks to make sure nothing bad happens, but the user can send specially crafted code (Javascript in that example) that will use Spectre to deduce what data lies in the same process beyond the boundary.
Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets.
No. Nope.
nononono.
not at all.
Spectre relies on speculative execution starting to handle instruction past some software check (ie.: array boundary check and then array access) and some side-effect leaking information (e.g.: loading things into cache).
You could only consider these programs as "following best practice" only by interpreting it as "do boundary check to avoid buffer over-runs". Nothing more.
Still it's only leaking information to which the process HAD ACCESS to begin with.
Which means that only a tiny subset of programs are susceptible.
More precisely the subset of programs which are stupid enough to keep the sensitive data in the same context where arbitrary code get executed.
i.e.: the Google Project Zero worked by turning on a special option in linux that allows user-provided (!) byte-code to get JIT-ed and executed in-kernel, which then in turn obviously has access to in-kernel data.
i.e.: there are affected browsers which keep sensitive data in the same context where they JIT and execute remotely provided Javascript (something which has "what could possibly go wrong" written all over it).
At least on Linux speculative execution cannot be used to access data *across* processes, because each process has its own address space.
i.e.: There's no virtual memory address that you can point your CPU to that contain data coming from a different process (unless it was intentionally shared across processes).
On the other hand, each process has the kernel mapped in its address space (though each process might get a different random mapping, thanks to things like KASLR), because it needs to call into it for system call (e.g.: call the filesystem to read a file).
That kernel memory is shielded from userland interference by memory protection (the process isn't allowed to read/write in the kernel space).
But due to the way Intel CPU specifically handle memory protection (in case of speculative execution, the access rights check is done too late, and some measurable side effects, such as bringing things into cache, might have happened already), on Intel CPU Meltdown manages to get around memory protection and leak kernel stuff into userland.
In fact, the safety checks of said best practices actually increase the attack surface and may make applications more susceptible to Spectre.
Given that Spectre is about things downstream form a safety check being in the pipeline before the check fails, you could say that in a stretch....
Spectre is harder to exploit than Meltdown {..} However, it is possible to prevent specific known exploits based on Spectre through software patches
Well given that Spectre is about leaking stuff to which the process has read-access anyway, it hard to exploit because it requires finding software with the right mix of bad design (mainly sensitive data and arbitrary code execution in the same process).
On the other hand, it's possible to just NOT design software in such "what could possibly go wrong ?" way.
but it is also harder to mitigate
Well, given that it's just speculative execution working as it should...
Spectre cannot be considered intentional tampering.
It's still speculative execution working as it should.
Only now has someone though of a way to exploit its (normal) side-effects.
But it only leaks data to which the process already had access to begin with.
Meaning that only a very tiny sub-category of software are affected, mainly software which run arbitrary code in the same context where sensitive data is stored (which is a very bad design flaw).
Google demo relies on a (for a reason) non-standard linux kernel settings, that allows user-provided arbitrary JIT-ed bytecode to be run in-kernel, that can then in turn leak in-kernel data.
And there are a few affected browser, that keep sensitive data in the same process where remotely provided Javascript is JITed and executed.
In other words : it's still a CPU working as it should, and only a tiny range of (badly designed) software affected : probably not intentionnal.
----
Meltdown is much more horrible (it's basically memory protection not working as it should. CPU doesn't work any more as supposed).
But given that Intel has done it for some tiny performance improvement (checking access rights late in the instruction pipeline is cheaper than checking it outright in the beginning as all other CPUs are doing), okkam razzor would tend to make us believe that Intel jumped at the opportunity to shave off a tiny bit of performance as they usually do, instead of some dark cloak conspiracy.
I'm not saying that government-sponsored spying doesn't exist, just that there's absolutely zero need to force Intel to jump onto some performance shaving trick that ends up being dangerous.
Technically, Spectre only reveals data to which the process had already access to begin with.
In the Google demo, it works because all in-kernel code (here: JIT-ed bytecode) has access to in-kernel data.
There's a reason why the option is non-standard.
In the few affected browser, it works because said browsers were stupid enough to keep sensitive data (passwords ?) in the same process as where remotely provided Javascript code is JITed and executed.
(I.e.: stupid design that should be fixed anyway. If not Spectre today, there's sure to be another exploitable flaw discovered before the end of this year which could also be leaking sensitive data. Always keep your sensitive data and arbitrary code execution segregated).
But correctly designed software should be unaffected.
On the other hand, Spectre only leaks information to which the process had access to begin with.
The CPU is still working as intended.
It's only badly designed software which as affected (keeping sensitive information in the same context where arbitrary code can be executed. ie.: Browsers that keep password in the same context as where the Javascript is executed, or a special non-standard linux kernel settings that enables an in-kernel JIT engine for the bytecode used by packet filtering - there's an obvious reason why this setting is non-standard !)
But basically Spectre doesn't open new access to restricted data.
Affected software should be fixed any way (i.e.: try to keep JITed arbitrary code away from sensitive data), because if not Spectre today, another different exploit coming this year could end up being just as bad. Sensitive data should just be kept away from arbitrary code execution, no matter what.
---
Whereas with Meltdown it's suddenly memory protection not working anymore as intented on Intel CPUs (they do the access rights too late, way after other side effects had time to happen), it's the CPU which is doing things wrong.
AMD isn't affected, because they did things formally correctly - mainly doing the access rights check at the beginning of the pipeline.
It's not that trivial to fix "in the wild": because of meltdown you just can't rely on memory protection anymore (the kernel isn't sage from user-land software anymore), the only possible fix are performance killer (at end of each call, the kernel must flush itself out of the space accessible by the user-land process).
Spectre is not the same thing. Multiple processor bugs were revealed.
Spectre is not a bug.
It's not suddenly accessing something which should not be accessed in the first place. It's not breaking memory protection, only giving data that the process can already read.
Speculative execution is still working as it should.
It just happens to have a side effect that got noticed now, and got used in timing attacks. (Just like any other timing attack).
But the CPU is still working as intended, it's not a bug.
Only badly designed software that keeps that doesn't properly isolates sensitive data and remotely provided arbitrary code that can be abused (some browser, some non-standard Linux kernel settings that are non-standard for a reason).
---
(This is completely different from Meltdown, where suddenly memory protection doesn't work any more. The process access things it was never supposed to access in the first place).
Meltdown uses out-of-order execution and a side channel attack that is unique to Intel. Spectre uses speculative execution and is more generalized, with tested proof-of-concept attack code on AMD and ARM.
On the other hand, Spectre only enables access to data to which the process had access to begin with. (Meh...)
Only a very small subset of software can actually be usefully abused, mostly due to bad software design :
- Google's demo relied on a non standard setting that turns on a JIT engine that runs user-provide arbitrary byte-code in-kernel (common, in-kernel ? What could possibly go wrong ! Seriously, there's a reason why this setting is non-standard).
- There are browser with bad designs that manage to keep sensitive data in the same context as remotely-provided Javascript code.
In other words, a problem waiting to happen. Spectre just happens to be the exploit which bit them now, but any other completely different exploit could have come in a couple of months and done similar damage.
Yup, it's bad that speculative execution may lead to some side effect, but it's working as intended.
It's the software which is stupid (or dangerous options turned on, as in the kernel) and should be fixed before another problems comes again.
---
Whereas Meltdown is an entire different level of worrying.
On Intel CPU, access rights are checked way to late, by that time speculative execution has had time to do stuff which can also be timed.
Other CPU (like AMD's) work much more sanely, doing the check first and not progressing anything. It cost a tiny bit of performance, but is more formally correct and ends up protecting against such problems.
That means that on Intel CPUs the whole set of guarantee that memory protection is supposed to give don't hold true any more.
It's the whole memory protection scheme flying out of the window.
On Intel CPUs memory protection has stoped working as it should.
The software is correct on relying on memory protection for security, it's Intel's protection that suddenly doesn't work anymore.
No matter if you write correct software.
On any other CPU protection works as it should, and non-stupid software is safe.
If the defect is in the microcode and they patch it in software, isn't it still vulnerable?
The defect that is happening, is that (by careful timing of cache) it's possible to see information to which the process has full access anyway.
The stupidity of some browsers is to store sensitive information in the same process as where the remotely provided javascript is JITed and executed, relying on "well, we do array boundary checks before reading them, so we should be safe from buffer overflows" for security.
Spectre works in a few corner cases because there are situation where software has full access to it's own data, but doesn't actually want to access any arbitrary data : mainly, it wants the Javascript to only read the data inside its array, and not outside were some sensitive information would be stored.
Which would fix ?
The blunder which gives access to already accessible data ?
The stupid software which keeps sensitive data and arbitrary code within reach of each other.
The first only works in a few key cases.
The second is a problem waiting to happen. If it's not Spectre today, it might be a completely different exploit tomorrow.
Doesn't seem like it would be difficult to undo or work around the software patch to access the original defective microcode.
The quick'n'dirty software correction would be :
- disabled JIT, so the arbirary code doesn't generate a thigh compact group of machine instruction that can all fit inside the CPU pipeline.
That's going to be order of magnitude more difficult to circumvent, at the cost of performance hit specific to the formelly JIT-ed code.
(But you still have a broken software that is going to get b0rken by the next coming exploit).
The formally correct software correction would be:
- keep the sensitive data and arbitrary code separate from each other. Thus even if a different exploit happens to your system, it would still not be able to access the sensitive data. You've fixed the problem forever.
The microcode/CPU correction would be :
- completely disable speculative execution, meaning a performance hit whenever there's a conditionnal jump in the code (basically everywhere).
You computer now runs like shit, and you still have broken-by-design software sitting waiting for the next exploit.
Side effects are something that is to be expected.
In case of spectre, speculative execution is happening as it shoudl, everything is having the correct behaviour.
There's no *formally wrong* behaviour to be patched in the CPU or in microcode.
There's nothing that should be patched in the CPU, the CPU works as intended, it just happens that this "as intended" produce a couple of side effects that where not noticed until recently.
It's just that researcher have noticed "yet another thing that can be timed" and thus a new side-channel that can be used to leak information.
The only novelty is it's built around a different CPU feature than other timing attacks.
It's still your gandpa's classical timing attack, only wearing a new fancy hat.
The main problem is that arbitrary externaly supplied code and sensitive data should never co-exist in the same process in the first place.
It's just problems waiting to happen.
(Seriously eBPF ? User supplied byte-code JITed in-kernel ? What could possibly go wrong ? there's a reason why that setting is non-standard)
Affected browsers (lots of them !) have basically a flawed design (running JITed Javascript code in the same context as some sensitive information reside). It just happens the spectre was the exploit that happen to reveal the flaw. But basically, it was just a problem waiting to happen.
IT NEEDS to be handled in the software anyway
(even if the CPU could suddenly stop doing speculative execution, e.g.: you switch to an Atom processor, there could still be yet another different exploit 2 months down the line that finds another way for Javascript to access all the information that reside in the process. Remove the sensitive data out of the process and you've fixed the software forever, no matter what exploits come here... well as long as the CPU respects memory protection, which is an entirely different level of wrong. Meltdown's level of wrong).
You just described IE6 (which was free)
Nope.
it only works on microsoft windows.
it's only a free bonus for people who have already shelled out money to microsoft.
By making people dependent on IE, Microsoft makes sure to increase the sales of Windows.
By making people dependent on Chrome, Google is supposed to profit how ?
and Microsoft (which bailed out Apple).
Which served them in proving that they are not covering 100% of the market of selling operating systems on personal computers.
"Look there's also Apple selling OSes ! They are still alive".
Google is selling what again ? Mozilla is selling what ?
They aren't covering 100% of sales and profit in a market, they don't sell anything and don't profit there.
Google profits by selling eyeballs =yours (and apps).
Their browser (and smartphone) business is entirely accessory.
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.
How could you start an antitrust suit on the grounds of Google Chrome ?
Google Chrome is given away for free (unlike the IE counter example, which was only available to those people who did buy Windows from Microsoft).
the source code of most of the parts (all the important one) is available to anyone (so anybody can re-implement a chrome-clone on their system of choice).
Google doesn't make a single penny directly out of Chrome.
In fact they don't even need you to use their browser, they just want you to use any browser. Mozilla Firefox could also do the trick (and that's why they are donating money into its development too).
Google doesn't give a shit about which browser, as long as you use *A* browser, and go online, where THEN in turn they can earn a ton of money thanks to their very lucrative ads business.
But the browser that you chose to actually bring you to these ads is completely irrelevant to their business plan.
The fact that you can one for free from Google (and another one for free by Mozilla, partly paid by Google's money too) is only a bonus.
(But a bonus which worth for them to invest into : the more free and easy solutions to go on line, the more eyeballs for them to sell to advertisers).
---
Note that, with a few exceptions (Google is licensing some parts commercially to big manufacturer - mainly the Google Services, and access to Google Play), the same logic also applies to Android (of which a good chunk is available with the source in clear) and which (can be) given away for free (at least AOSP part).
They don't profit from Android (much - there are still the licenses), they profit from people going online (again to be subjected to ads) and coming to pay apps from their Play store.
There's a difference.
Internet Explorer back then, locked you into a shit ton of closed source proprietary secret poorly documented stuff (embed OLE objects/ActiveX extensions night mare).
There was no sane way to make a web app specifically made for IE to run on anything else except the specific version of IE that it was made for.
Google Chrome mostly relies on open standard. Take another browser that complies with the same open standard, and you can more or less access the same web apps.
Chrome's source code is even accessible. When in doubt you can check how they've implemented some non-compliant stuff.
In practice, very few web apps run in Chrome but completely fail in Firefox, despite both using entirely different engines.
Yes, a lot of web apps fail in Microsoft Edge /Internet Explorer or in Safari, but has more to do with those being bullshit browser which aren't up to date with standard (microsoft's stuff even more so) than Chrome being a proprietary target.
And then, there's the whole anti-trust / profit angle.
Back during the internet explorer scandals, Microsoft was profitting from selling software. By making sure that as many websites and webapps only work exclusively with IE, Microsoft made sure that people desperately need to buy Windows from them in order to get the bundled in Internet Explorer.
Nowadays, Google doesn't profit at all from Chrome. Their hugest profit driver is matching *results* (though not the search results themselves in Google.com, mind you. But matching ads to serve best to end users. And matching content to keep youtube users hooked while they play ads. etc.)
They don't give a shit if you use their browser. They want to use *a* browser, *any* browser, might as well be Firefox if not Chrome (which they *also* finance - Google is pouring money and financing what some could wrongly consider their "main competition").
As long as you end up using this browser to go online, where they can thrown ads at you and sell your eyeballs to the highest bidding advertiser, and where they can monetize the shit out of all the online behaviour data they can gather about you.
Chrome isn't a product on which Google is making money (directly).
Chrome is just one of the possible tools that make their actual business (profiting of users going online) possible.
You can hardly suing them for antitrust violations, Chrome is free (i.e.: "gratis" as in beer) as well as major part free software (i.e.: "libre" as in freedom to look into it and build your own browser).
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
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.
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.
What is this penchant so many engineers have for adding needless complexity to (what should be) relatively simple, single-purpose devices? {...} This is now just another thing that can and will go wrong with an already-expensive device, almost certainly shortening its usable lifetime
This xkcd is actually relevant here.
In this case it's not complex at all.
The 900 series is already making a map of its surrounding as it works (unlike its predecessors, it doesn't random dance. It constantly tracks its exact position using a camera a bit like an upturned mouse).
It already records per-position information from its sensors in this map (mostly related to sensors that detect presence of dirt).
It has an always-on wifi antenna,
so recording the strength of signal as goes around drawing it's map comes for free.
It's not a needless complexity, it's just about adding 1 line of code to their program and suddenly having a new fun feature.
---
the questions lie more upstream :
- was it really worth adding the mapping feature ? it's a complex power-hungry feature, but in the end of the day, unless you have an extremely weirdly shaped flat (are Escher and Dali your architects ?) the "randomly going aimlessly everywhere until everything is eventually covered" of the predecessors works equally well.
The only difference is that now the roomba can stop cleaning, go back straight to the dock to charge, and then resume where it was. So if you want to clean NASA-sized hangars over several charging cycles, it might be worth it...
- was it really worth adding Wifi, so that not only can you use you smartphone as a remote (like the bluetooth enabled 800 series predecessors), or an actual IR or proprietary-ZigBee-like stuff remote like previous models (up to 700), but now thanks to wifi you can also optionnally connect it to the cloud and send it cleaning commands from outside the house ?
I doubt there are that many use cases where this is necessary.
Though on the other hand, the security implication are much lower. (It's a cleaning robot. It doesn't have that much processing power. It's doesn't get an actual video stream from the camera, but a list of high-contrast points from the DSP connected to the cam. There isn't much to be gained from those points if a bug accidentally leaks them online. My metaphore of up-turned mouse is apt as a mouse also doesn't send a video feed to the computer)
This will likely turn into another massive violation of people's privacy
I don't know if this is going to open any much more danger than before :
- the roomba 900 already make a map of the floor.
- the roomba is already connected to your Wifi.
Storing the strengh of the connection as the map is built doesn't give much more risks.
And even the current Wifi getting hacked shouldn't disclose too much stuff.
(Due to limited computing power budget, the Roomba 900 don't actually "see" only get very precise position from their pseudo-mouse).
Followed soon on by a third thought:
- Never buy a Roomba
Actually : never skip doing some research before buying any expensive toy.
In fact :
- Nearly all vacuuming robots, including absolutely all of their competitors, and including irobot's roomba 900 series and braava, all make a map of their surrounding (though not all are internet connected).
Irobot was simply late at the game (because, as noticed above, it actually doesn't bring much in practice. It just looks less messy to an observer).
- All older roomba (up to 800 serie, and their scooba) (also a few other manufacturer who have sublicensed the design) (as well as no-name asian clones of these) don't do any mapping, they just aimlessly wander around until everything is eventually covered. (But as proven by long-exposure photos, it basically gives the same end result). None of them have any internet connection, only 8
Roomba model comparison chart. Go ahead, you don't have to buy anything. Look. What do you see?
The first thing I saw, is that they have multiple models. Gotta admit, I didn't know that.
Check out the bullet points. There are some dubious "features" there, but a couple stand out, almost as negative things where you might think "WTF, some Roombas can't do that?"{...} The multi-room cleaning "feature" shocked me too. Does that mean with the cheaper Roombas, you have to get one for every room? Fuck that.
Well most of the things on this list are exactly that : stupid arbitrary checkbox points, nothing more.
Basically cheaper roomba have smaller batteries than more expensive one (so they can only clean for a shorter amount of time until they need to dock back for charging). But that's about the main difference.
Newer roomba (since the 800) have a bit better roller which might get a little bit less mess, but not by much. But they still sell the olders because they still have them in their warehouse and they are cheap now that they try to get rid of them.
The 900 serie is completely different, in that it uses a camera to track its exact position (think a turned-up optical mouse). So it doesn't randomly dance everywhere until it has covered eventually the whole floor, instead it makes neat orderly grid zig-zags.
But unless you have an extremely weirdly shaped flat, it doesn't matter much, both methods will cover everything eventually, one just looks a tiny bit more oderly from the outside.
That means all robot can clean multiple rooms, the battery run time is the only limiting factor.
(The 900 being the small exception : as it knows it position it can return to dock, charge, and resume cleaning. It can thus clean a surface much larger than what could be done on a single charge. So if you planned to clean a giant aerospatial hangar, you might need one).
etc.
It's about upselling. I think that's 100% of it. But maybe we all have different buttons to press, and what gets me to think "I have to get a Roomba 960 or else there's no point in getting any Roomba at all" is different from what might make you decide to get a 960 or none at all. ;-)
Yup. It's a huge marketing bullshit to make the more expensive look more desirable.
But let's say your spouse wants one, and it's decided: you're getting something. Maybe another stupid fucking bullet point would push your button.
Or you know, maybe like whenever buying any expensive gadget, you read some review, or even better, ask friends who have one for advice.
And then realize that maybe the cheap one actually does the job for you.
If that device would make an internal map of it's cleaning thoroughness, i. e. how often it covers an area, that may be useful for trusting this thing
Actually, that the whole purpose of Roomba 900 series (and Braava) : they are able to know their exact position,
and thus can draw a nice map of where and how often they've been.
(But in the end, they actually aren't that much more efficient that their "random dance" predecessors)
Making a map of wifi signal basically comes free for a device that already automatically maps its surroundings and has an always-on wifi antenna.
Roomba 900 are mapping robots (unlike their predecessors).
They don't do random dance. They know their exact position in the map and are bit more orderly in their path.
So, instead of a poopocalypse, you're look in forward, for a very meticulous precise and neat poop grid zig-zaging across your floor.
The by-now-4-yo kid will smell like poop when walking to your room all the same.
Roomba, all the way up to the 8xx serie (and Scoobas, btw), still do "random dance around".
They aimlessly go in any random direction, bump into things, etc. eventually, they'll end up covering the whole surface by the end of the program.
At no moment do they have any idea where they are. They just notice the dock when they happen to come by in front of it during the random dance.
(Also they don't have any Wifi. They either have some weird custom proprietary of ZigBee (up to 700 series) to communicate with the non-IR remote and with automatic lightwalls, or have Bluetooth (800 series) to communicate with your smartphone)
In case of cat throw-ups, they'll still enjoy making abstract art in your living room, with the occasional spiral shape thrown in for good looks.
Roomba starting with the 9xx serie (and Braava) having mapping capabilities (older Braava detect a set of IR laser points projected on the ceiling by a special "Northstar" navigation cube. Newer hardware has a webcam, and a DSP that extracts a set of "high contrast points"). The roomba exactly knows where it is at any moment of time and thus can build a map of the place.
Because it has an exact known position and a rough map, it doesn't wander aimlessly, but does precise S lines accross the floor.
(It also covers everything eventually, end up being measurably the same performance as the random work, but looks a little bit better from the outside).
Because of the same, it's also able to directly head for the dock when needed, and can resume cleaning where it left once charged.
It also comes with Wifi for communicating with the smartphone (and optionally the cloud).
In case of cat throw up, it will very meticulously spead it in straight zig-zaging line across your floor, eventually building a nice grid.
So which cat trow up artwork you like (abstract vs meticulous grid) depends on your taste, but your dog will still enjoy licking it all the same.
(More seriously: The reason they can do wifi maps before perfecting the cleaning is simply because the maps come for free for a device that already has mapping technology plus an always on wifi antenna).
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
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
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.
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).