Leaking a user space program's own information can be a serious risk especially if that program can also execute arbitary code.
Yes, but although the fact that checks (e.g.: array limit checks done in software) don't work perfectly is a problem per se, the fact that YOU ARE RUNNING ARBITRARY CODE in the first place is the main problem here.
In other words, using rust is a nice thing, but it doesn't stop you from writing stupid code in the first place. (to play with all the usual "rust-troll" that come screaming for out-of-bound checks whenever there's memory overflow exploit mentioned)
A web browser is an example of such code. They have done a proof-of-concept where Javascript running on Chrome can leak information to a remote attacker information within Chrome's memory space. This could include sensitive information such as authentication tokens, private keys, the content of Chrome's password manager, etc.
This is the main reasons why there's been efforts in trying to separate things into isolated processes.
Chrome is using separate process tabs. Back in the old XUL days, Firefox was using a separate process for Flash (a.k.a.: exploits fire hose). Now with the big XUL-to-webextension, Mozilla can even turn on electrolysis in Firefox and join the "separate process" bandwagon.
No matter of checks, etc. will be enough in browsers. - You need to keep the sensitive information and the abitrary remotely-provided code in separate process. (A javascript running while you browse Facebook can logically access your FB token/cookie, but should in no way read the rest of your password manager's content). - You need to keep the amount of remotely-provided arbitrary code as low as possible (ideally, using a white-listing pluging like the NoScript web extension).
If I'm reading this correctly, older Intel Atoms are safe because they are in-order CPUs ( https://spectreattack.com/#faq). I still have an Atom from 2010, and it's already slow enough so I'd rather leave it without KPTI. Of course, my important servers are all AMD.
...and same for Xeon Phi. (Which are basically the same kind of in order approach like Atoms, but linked together with a ginormous SIMD unit - the AVX512 - some kind of ultra-SSE/AVX on steroids that border onto GPU territory. That shouldn't be a surprise, as Xeon Phi are basically what Intel salvaged out of their failed Larrabee GPU experiments).
According to the Wikipedia article about Atom architecture, there's only one single micro-ops ever in flight from a given process (though they DO hyperthreading and might fill unused slot with micro-ops coming from a different thread), and don't do any speculative execution at all : At no time can you reach a situation were some check (e.g.: a software "rust-style" boundary check, like in the bug also affecting AMD too, or the MMU enforcing memory protection as the bug affecting Intels only) hasn't completed yet, but the invalid read has already started entering the pipeline.
You cannot leak stuff using speculative execution on a CPU that lacks any form of speculative execution, indeed.
(So if the rushed correction enables kpti on your setup, you can safely disable it by giving "nokpti" to it).
Actually, when a user-land process contains sensitive data and can run arbitrary code, it is a serious flaw.
Yup.
And in the case of today's bugs, the level of "arbitrary" is concerned.
- Without the bug, one would need full absolute control like reading from any random memory location. If there's a check against reading this, you can't get the content. If the code doesn't offer you full unrestrained pointer math, you can't do this.
- With the bug affecting AMD too, even if the code tries somewhat limit you in what you are allowed to read (the boundary check heralded by the Rust-troll that show-up when ever there's a buffer overflow exploit mentioned), the check might not have completed by the time the read-access is starting to enter the pipeline and you could end-up having measurable leaks (side channels).
- With the bug that affects Intel-only, none of the guarantees offered by memory protection holds true anymore. You can as well throw your MMU out of the window. Even if memory protection should prevent a piece of software reading the kernel's data, that can be leaked too.
For example a web browser: contains in its memory space user passwords, authentication tokens, private keys etc. and can run arbitrary code from a remote source (Javascript).
Which is why browser like Google's Chrome, and like the elecrolysis that Mozilla's Firefox managed to enable once the big XUL-to-WebExtension switch happened (or the separate process used for Flash back in the WebExtension era), try to isolate stuff in separate process.
i.e.: - Ideally the password managing bits and the tabs running remotely provided javascript should be kept in separate process that can't see each other. - In practice there was recent mention of some password manager pre-filling forms in tabs (under some circumstances this can happen in Firefox) and thus making it visible to the javascript running there.
To mitigate the Intel CPU bug, each time your software calls a kernel function (e.g.: filesystem, to access a file), the kernel needs to flush it self out of the accessible address space. Basically each single system call suddenly comes at the same cost that a full blown task switching.
Benchmarks that call a lot of system call (basically, anything that isn't purely 100% number crunching. i.e.: nearly any real-world application) are going to get a big hit.
Spinning disk aren't affected much (waiting for the big latencies until data gets there is dwarfed by the call hits).
As I read it, best case, all of userland is compromised.
Not *all* the user land. Only all the memory space that is accessible to the process being abused.
In the AMD case, a user-land exploit (or in-kernel, with some weird kernel settings to allow such code to happen) can only leak information from the memory it has access to (Yay!).
It means that an app can leak some of its information even if it didn't want to. And it means that if you get the kernel to execute some user supplied (JITed byte-)code, the kernel can leak some kernel data (but nobody sane should enable non-standard options that invite user-supplied code in the kernel).
An process cannot leak information from another process that it cannot "see" (= it needs to have the other process' data mapped into its current address space, in order to have an address to read from).
Any protection guarantee that stem from memory protection still hold true.
In the Intel case, the main take-home message, is that suddenly memory protection doesn't hold true any more. A process can guess data at any address, even if it doesn't have the access rights to that location.
Which is several order of magnitude of "scary" above the former situation.
And those situations are a process leaking it's own memory space.
You need to first manage to send code to be executed in the memory space of something containing the interesting information to be able to get it, you can't do it from your own process.
(e.g.: Google's Project Zero managed to exploit a non-standard kernel setting that allow you to send eBPF - the bytecode used by modern packet filtering - to a JIT that will run it in-kernel. It's in-kernel software access in-kernel data. You get what you deserve for inviting user-supplied code into your kernel).
On the other hand the Intel CPU flaw allows you around the boundaries that are normally guaranteed by memory protection.
AMD does not have the read-kernel-memory flaw but it does have the read-other-userland-process-memory flaw.
I'll have to re-read the google publication, but I was under the impression that a process can only leak it's own memory space. (because that one is just about out-of-bound accesses). The javascript would need to somehow convince your ssh-agent to run some code in its address space to successfully extract the keys.
Basically each process has a different memory map. Some addresses maps to its own data (for obvious reasons). Some addresses maps to kernel stuff (so it can call system calls : filesystem accesses, etc.)
There's no address that the Javascript could attempt to read to trigger anything dependent on the ssh-agent. It can only access addresses that refer to the data of the browser executing it (or more precisely, the current browser process - in case of multi-processing browser like Google's Chrome, or like the post-WebExtentsions-only-no-XUL FireFox's Electrolysis. It won't be able to even see other tabs: there's no memory address that would point to that content)
The only way the Project Zero proof of concept worked was by using a non standard setting to send eBPF (the bytecode used by modern packet filtering) into a JIT that run-it in-kernel (so basically it's an in-kernel process that leaks its own in-kernel data, and you get what you deserve for allowing user-supplied (byte-)code to run in-kernel).
And according to the various docs, the mitigiation against these forms of attacks is rather trivial.
the Intel CPU-specific flaw is an entirely different can of worm. Most crucially, the mitigation against it comes at a ginormous performance cost. Basically, each time your app calls into the kernel (e.g.: calls the filesystem to read something from a file), the kernel needs to flush itself out of the accessible memory. On Intel's CPUs, each system call will suddenly come at the same cost as a whole multi-processing switch, even if all happens within the same process. Each single system call now comes with a craptastic performance hit.
Intel saying that it won't affect significantly average end users ? (Well in the same way the pentium floating point didn't affect them ?)
Well, maybe average users that only use their machine to surf Facebook. They have been running machine way much powerful than needed any way (very seldom do they have any core saturated at 100% use), so they simply won't be noticing the ~30% performance hit. (Who care if their web page loade in 50ms or 100ms ? It's twice the speed, but still under the noticeable threshold).
But for lots of power users (e.g.: gamers) that performance hit is going to be painfully noticeable. It's going to show up in benchmarks. It's going to show up in CPU intensive tasks. It's going to drive a bit some of the market choices.
About the only truly users who won't be affect that much, is scientist running computations that mostly do number crunching (not much kernel switching involved).
Yeah so the fact that some obscure ARM64 demo board that hasn't seen that much actual real-world deployment (*) happens to be made by AMD, means that suddenly everybody must lose confidence in all x86-64 hardware, not only Intel's (which is totally affected by the security shit storm) but also AMD's (whose AMD64 is immune to the actual security leaking exploit. It's not affected by the security shit storm. It's just affected by some proof of concepts where an application can leak it's own memory space) ?
While technically, the words of Intel aren't completely wrong (yup, there exist an obscure chip made by AMD that is affected), it's completely misleading: they want to make you think that it's affecting all manufacturer across the board similarly. It's not. Most of what AMD produces, all the chips you might be thinking about when thinking of AMD (i.e.: the AMD64 chips that make a sizeable chunk of AMD's production, and nearly all of their CPU production), they are not affected.
--- *: honnestly, are there any significant number of machine shipped with Opteron-A ? I mean actual servers deployed in production widescale, not some SBC sold in small quantity to people wanting to experiment with the tech.
They are affected, but not by Meltdown but by Spectre
To expand :
The whole shit storm affecting Intel, is about boundary violations. That means kernel information leaking into user-land software.
Intel CPU are affected by this (they check access rights much later on, at a point where a lot has happened and that "lot" can be carefully timed and analyzed to leak information out of the kernel space). It allows to have information cross the boundary between kernel and users-space.
AMD CPU are not affect by this (they check access rights ealier, at a point where not much has happened yet). Yes you can also do timing to guess stuff from speculative execution, BUT you are shut out of the kernel space. You can only user this to have one process leak its own memory space. You cannot use this to get things from the kernel into some javscript code, the CPU will block access to early for the attack to actually work.
Yeah, I'm sure a user-land process being able to leak it's own memory space is a serious flaw... Yay!...
(The only way Google could even demonstrate it, is by enabling some non-standard kernel setting that let you sent eBPF (the byte code used by the packet filter) into a JIT which will run it in-kernel. Thus in-kernel process has access to in-kernel memory space. And you get what you deserve for inviting user-supplied code to run in-kernel)
Yes, you can also time stuff to get information from speculative execution on AMD CPUs. Except that, due to better security hardware implementation you CANNOT use this to get information accross the kernel fence straight into user space.
With Intel, you end up with a situation where some Javascript code (demo'd at CCC) running in one of your browser tabs could be leaking information straight out of your kernel.
- old, in-order, non-pipelined CPU like the 6502 in your good old trusted C64 don't do speculative execution and thus aren't affected specifically by such exploits.
but:
- your 6502 doesn't do any form of memory protection : any piece of software can access any part of the whole system (because poking weird memory location is how you control the hardware on such old system) so any software has full access to anything. So you C64 is leaking sensitive information.
(Later 68k motorola CPU (68030 and up) eventually started to include an built-in MMU to protect memory access, and thus later Amiga machine featuring them (A2500/30, A3000) can be made imune to OS information leaking into userland. That would the first Comodore hardware - vaguely remote cousin of your C64 - to do so)
AMD checks access rights first and if rejected nothing much happens. Meaning no leaks from kernel information into user-space running software. - Google only demonstrated a in user-space software accessing its own in user-space info. - And by using some non standard settings, it's possible to give bytecode to that kernel, and that piece of in-kernel software will access its own in-kernel info. (But you're already on the other side of the kernel fence) Nothing gets accross the kernel fence.
Intel checks access rights much later on. By that time quite a lot has happened (e.g.: things could have been loaded in the cache, etc.). By measuring those things, you can deduce information that you should not have access to. It means that a user-space software could end up getting sensitive information that normally should stay in-kernel. These subtle timings of cache enable you to get information accross the kernel fence into user-land. To mitigate these, each time a user-land software calls into a kernel function (e.g.: filesystem access), the OS needs to flush all it's space from the accessible space. This comes at a big performance cost.
AMD actually don't violate boundaries. As in their LKLM post, they do the access rights checks before anything else, and if rejected nothing much happens that can be timed. Meaning there's no leaking of kernel information into user-space programs.
The only thing that Google successfully demonstrated is : - leaking some users-space's program own information (yay!...). There's not much boundary violation here. - using some non-standard linux kernel settings, to send eBPF (the bytecode used by modern packet filtering) to a JIT that will execute it in kernel. You end-up with in-kernel code being able to leak its own in-kernel information. That might give possibility to create some scary constructs, but ISN'T a violation of boundaries (you're already on the other side of the kernel fence) and requires non-standard settings (which basically amount to giving possibility to execute user-supplied (byte-) code in-kernel. So you basically get what you've deserved for inviting users into your kernel)
On the other hands Intel CPUs do violate boundaries : It does quite a lot before eventually deciding to kill the invalid access. All this "lot" are things that can be measured afterward, meaning that information from the kernel can be leaked into the user-app.
The horrible leak that gives access of kernel information to any userspace software that was revealed yesterday doesn't affect AMD64 : AMD processor reject invalid access much earlier in the pipeline and nothing much happens before that point (e.g.: loading into cache) that could be measured by timing, etc.
In the google paper, they are abusing a different set of anomalies were an application end's up reading it's own memory (yay... ). That *could* be affecting AMD64, but : - it's only an application in user-space accessing it's own in user-space memory. - by enabling a few non-standard kernel settings, you end up with a situation where you can send eBPF (the bytecode used by modern packet filtering) to a in-kernel JIT, and it's execution will end up with some in-kernel code reading its own in-kernel memory.
The main big difference, the take-home message:
- on Intel CPU, you have a violation of boundary separation : an end-user application could access information leaking out of the kernel. - on AMD CPU, this does not happen : you only access information on the same side of the separation boundary.
Or in other words : - On Intel are in deep shit right now. They need a serious circumvention around it. It means context switch - each time a software calls a system call (e.g.: to access the file system) - the OS needs to flush out all the sensitive information to make them unreachable by the exploit. The end result : massive performance hit.
This is more of a server attack and a web host attack.
No, it's not specific to web servers. They do use web servers as an example of where the exploit might be applied, but it's not specific.
Basically, this exploit allows to abuse the way speculative execution is done to leak information out of the kernel space into the user space. (And there are presentation at the CCC of successful abuses done... in Javascript. In a browser).
For more details :
most modern CISC processors (Intel - except for Atoms and Xeon Phi - AMD, etc.) are pipelined and do out-of-order execution. Executing a CISC instruction requires several steps (micro-ops) and for performance reasons, they keep several instruction in flight (Once instruction A goes out of step 1 and into step 2, you can try already pushing instruction B into step 1). To gain even more performance, CPUs try to be clever about this (instruction B actually needs results of instruction A, so it needs to wait. But the next instruction C actually can already be started, it doesn't depend on anything still in the pipeline). Bordering on crystal ball-clever (the next instruction B is a conditional jump. But it looks like a loop, so there's a high chance that it will jump back and repeat. We might as well start working back on instruction A, in case we are correct about this jump). That's speculative execution : working in advance on stuff that might not even be needed. (Sometimes, you end up needing to bail out of your speculation, throw the work away and restart because you got your crystal ball wrong. But it's better than just sitting there waiting).
now about memory : any modern processor worth its salt has memory protection, meaning it handles access rights : Which process can read-write which virtual addresses ? Usually, sensitive information in the OS is shielded away from the regular software. On a modern Linux, you can't crash the whole system by writing junk at the wrong address, like you used to do in the old MS-DOS days. If your software attempts to read something out of the system, the read attempt will be rejected.
the exploit relies on how these both play together.
It happens to be that, in the case of Intel's processors (but not of AMD's), the step where the memory page is loaded from the DRAM stick into the cache happens before the check if the read is valid. By the time the Intel CPU does the check and notice that the read is invalid and rejects it, quite a lot has happened. (Things got loaded into cache, other instructions have started their speculative execution in the pipeline, etc.) These things are measurable (you can measure the timing of some computation to guess what's in the cache and what's not).
Meaning that it's possible to leak sensitive information, that normally pertain in to the OS and shouldn't be application-accessible, by doing a ton of such speculative-execution and timings. At CCC there was some presentation of this done in javascript: Technically, your browser right now could be executing some random javascript shit from some shaddy website in one of your background tabs and trying to learn as much from your OS as possible. Such information could further be used while mounting privilege escalations, or other attacks.
In the specific situation of AMD processors, the check is done much earlier (according to their lklm post) and thus not much else has happened already, and there's not much leak from which you could learn.
I have no idea how ARM64 are affected. (But it might also be the cache getting populated before the read attempts get rejected).
The OS devs patching a security hole in the CPU should not leave them open to a lawsuit when the only way to patch it slows down the performance of the system.
Well, not exactly the only way. One way is to run the upgraded kernel, which will use the fix to circumvent the big CPU flaw, but will take a massive performance hit. The other way, is to give "nopti" boot param to this new kernel, which will run it as-as with no fixes, which will leave the performance untouched but which is something you would definitely only do on machine that never ever run foreign untrusted code (which according to TFS, also includes javascript).
OS devs just give you a possibility to circumvent the CPU flaw and are cautious as usual to enable the fix by default (for security purpose) and give an option to disable. It' still something which is optional, up to the choice of the user (even if by default the devs have sided on the security aspect).
On the other hand, Intel are the one who have delivered a pieces of hardware which doesn't work as advertised. (Or could be made sort-of working if you use a performance-killing circumvention).
I don't know, but maybe he runs an high performance computing (HPC ) cluster.
With compute nodes segregated on a separate network that might not even have internet access, and certainly not running random javascripts downloaded from random websites.
And in these context, performance matters a lot, while security is handled in a "perimeter" fashion.
In those cases, it makes sense to have an option to disable the fix.
Playing God with the procreation process is usually a civilization destroying process.
What do you mean by "usually" ? You have a long list of civilisations all destroyed by the process of "Playing God" with the procreation process ? Like a dozen of such cases, to illustrate that indeed that's the most usual out-come ?
The only instance of "Playing God with the procreation process" is the development of agriculture over the past couple of millennia (hybridizations, selections of weird nearly-impossible offsprings, agricultural crops being so much different from their nearest natural wild relative to be almost unrecognizable, polypoloidy being common in agricultural crops, etc.) and that has in fac turned out quite successful when you look at the evolution of what meal is in your plate.
Myriad's Aliendalvik anrdoid layer on Jolla's Sailfish OS more or less works.
The draw back is that it's still based around the "almost not Java" Dalvik JVM-like JIT engine, (well not exactly. It's Myriad's own variation of Dalvik) so it's still stuck in the world of Android 4.4 Kitkat (so no support for Android 5.0 Lollipop only apps).
The other draw back is that Sailfish OS it selfs lacks drivers and frameworks for some hardware feature (e.g.: finger print scanners. There's a raw device showing up in/dev/ but that's about it), or doesn't have the necessary wrapper to forward other stuff from Gnu/linux world to Android (e.g.: bluetooth. Sailfish OS has a functioning BlueZ, but no wrapper to provide it with the BlueDroid api used on Android Apps. Meaning that some device work - e.g.: bluetooth speakers are handled by bluez and pulseaudio, and android simply see an audio-out and music correctly plays in Spotify, etc. - but app needing low-level acces don't - e.g.: the manufacturer's app to change the configuration of the same bluetooth speaker doesn't work).
Still it runs the majority of apps I've tried on it, (including common stuff like WhatsApp, Instagram, Skype, Messenger, Firefox, my bank's 2 factor app, etc.)
Jolla also has an Aptoid repository with curated APKs that are known to be compatible with Alien Dalvik (the Netflix version available there does work).
I have no experience with BlackBerry's compatibility layer. I have no experience with Tizen's layer either, but I've read good reviews.
Regarding Windows, Microsoft never managed to get it to work, hence the change of focus to WSL (Windows Service for Linux - a.k.a.: "Bash in Windows").
The subtle difference, is that in France (and somewhat in other countries such as Switzerland) a substantial part of the movie theater are own by corporations such as Pathe / Guamont. which are also movie studios and movie distributor (i.e.: the whole thing is a lot more vertically integrated).
Meaning it's much more easy for them to negociate the price of the movie ticket, because they are also the distributor of the movie.
Will it be perfectly efficient ? For sure, not. (I mean even the Palm/HP's Touchstone surface induction system, which - unlike the Qi system mentioned in the summary - uses magnet to better align the phone with the induction surface, isn't very efficient neither, despite being as close to the emitter as possible)
Will it be a tiny bit better than plain blasting from a globally diffusing antenna ? Sure, it's going to be a tiny bit better.
It’s surprising the FCC approved it.
FCC's (and similar body is other jurisdiction) only job is to regulate things which might be dangerous and/or damage or disturb other radio equipment.
They don't give a damn if it makes sense economically or in terms of efficiency.
I remember reading about this years ago, and was under the impression that this had been fixed by browsers filling the form fields in the UI, but not in the DOM, until the user explicitly selected one of the fields in the same form.
That's the case in Firefox : - you need to click on either the username or password field to get a pull-down menu that gives you information about the login, and gives you a selection of passwords saved in the manager.
Also, with most browsers you get extensions like Block Origin, AdBlock Plus, etc. which are going to block most common advertisers.
And extensions such as Privacy Badger which is going to block most common tracker.
And specifically in Firefox (because it requires to either have the new additional extensions that they've added to web extensions to enable this kind of software in the latest firefox, or to have the XUL API in the long term support version) you can also have NoScript, which is going to block all non-explicitely-authorised JavaScript (so tracker missed by the blacklists of UBO, ADP, etc. are blocked anyway), and provides additional alerts against cross site scripting (XSS).
Remember: just as you never fuck without condom, you never surf without your security extensions.
Slashdot Mirror
Leaking a user space program's own information can be a serious risk especially if that program can also execute arbitary code.
Yes, but although the fact that checks (e.g.: array limit checks done in software) don't work perfectly is a problem per se, the fact that YOU ARE RUNNING ARBITRARY CODE in the first place is the main problem here.
In other words, using rust is a nice thing, but it doesn't stop you from writing stupid code in the first place.
(to play with all the usual "rust-troll" that come screaming for out-of-bound checks whenever there's memory overflow exploit mentioned)
A web browser is an example of such code. They have done a proof-of-concept where Javascript running on Chrome can leak information to a remote attacker information within Chrome's memory space. This could include sensitive information such as authentication tokens, private keys, the content of Chrome's password manager, etc.
This is the main reasons why there's been efforts in trying to separate things into isolated processes.
Chrome is using separate process tabs.
Back in the old XUL days, Firefox was using a separate process for Flash (a.k.a.: exploits fire hose).
Now with the big XUL-to-webextension, Mozilla can even turn on electrolysis in Firefox and join the "separate process" bandwagon.
No matter of checks, etc. will be enough in browsers.
- You need to keep the sensitive information and the abitrary remotely-provided code in separate process. (A javascript running while you browse Facebook can logically access your FB token/cookie, but should in no way read the rest of your password manager's content).
- You need to keep the amount of remotely-provided arbitrary code as low as possible (ideally, using a white-listing pluging like the NoScript web extension).
If I'm reading this correctly, older Intel Atoms are safe because they are in-order CPUs ( https://spectreattack.com/#faq). I still have an Atom from 2010, and it's already slow enough so I'd rather leave it without KPTI. Of course, my important servers are all AMD.
...and same for Xeon Phi.
(Which are basically the same kind of in order approach like Atoms, but linked together with a ginormous SIMD unit - the AVX512 - some kind of ultra-SSE/AVX on steroids that border onto GPU territory. That shouldn't be a surprise, as Xeon Phi are basically what Intel salvaged out of their failed Larrabee GPU experiments).
According to the Wikipedia article about Atom architecture, there's only one single micro-ops ever in flight from a given process (though they DO hyperthreading and might fill unused slot with micro-ops coming from a different thread), and don't do any speculative execution at all :
At no time can you reach a situation were some check (e.g.: a software "rust-style" boundary check, like in the bug also affecting AMD too, or the MMU enforcing memory protection as the bug affecting Intels only) hasn't completed yet, but the invalid read has already started entering the pipeline.
You cannot leak stuff using speculative execution on a CPU that lacks any form of speculative execution, indeed.
(So if the rushed correction enables kpti on your setup, you can safely disable it by giving "nokpti" to it).
Actually, when a user-land process contains sensitive data and can run arbitrary code, it is a serious flaw.
Yup.
And in the case of today's bugs, the level of "arbitrary" is concerned.
- Without the bug, one would need full absolute control like reading from any random memory location. If there's a check against reading this, you can't get the content. If the code doesn't offer you full unrestrained pointer math, you can't do this.
- With the bug affecting AMD too, even if the code tries somewhat limit you in what you are allowed to read (the boundary check heralded by the Rust-troll that show-up when ever there's a buffer overflow exploit mentioned), the check might not have completed by the time the read-access is starting to enter the pipeline and you could end-up having measurable leaks (side channels).
- With the bug that affects Intel-only, none of the guarantees offered by memory protection holds true anymore. You can as well throw your MMU out of the window. Even if memory protection should prevent a piece of software reading the kernel's data, that can be leaked too.
For example a web browser: contains in its memory space user passwords, authentication tokens, private keys etc. and can run arbitrary code from a remote source (Javascript).
Which is why browser like Google's Chrome, and like the elecrolysis that Mozilla's Firefox managed to enable once the big XUL-to-WebExtension switch happened (or the separate process used for Flash back in the WebExtension era), try to isolate stuff in separate process.
i.e.:
- Ideally the password managing bits and the tabs running remotely provided javascript should be kept in separate process that can't see each other.
- In practice there was recent mention of some password manager pre-filling forms in tabs (under some circumstances this can happen in Firefox) and thus making it visible to the javascript running there.
It basically boils down to system calls.
To mitigate the Intel CPU bug, each time your software calls a kernel function (e.g.: filesystem, to access a file), the kernel needs to flush it self out of the accessible address space.
Basically each single system call suddenly comes at the same cost that a full blown task switching.
Benchmarks that call a lot of system call (basically, anything that isn't purely 100% number crunching. i.e.: nearly any real-world application) are going to get a big hit.
Spinning disk aren't affected much (waiting for the big latencies until data gets there is dwarfed by the call hits).
As I read it, best case, all of userland is compromised.
Not *all* the user land.
Only all the memory space that is accessible to the process being abused.
In the AMD case, a user-land exploit (or in-kernel, with some weird kernel settings to allow such code to happen) can only leak information from the memory it has access to (Yay!).
It means that an app can leak some of its information even if it didn't want to.
And it means that if you get the kernel to execute some user supplied (JITed byte-)code, the kernel can leak some kernel data (but nobody sane should enable non-standard options that invite user-supplied code in the kernel).
An process cannot leak information from another process that it cannot "see" (= it needs to have the other process' data mapped into its current address space, in order to have an address to read from).
Any protection guarantee that stem from memory protection still hold true.
In the Intel case, the main take-home message, is that suddenly memory protection doesn't hold true any more.
A process can guess data at any address, even if it doesn't have the access rights to that location.
Which is several order of magnitude of "scary" above the former situation.
AMD can be vulnerable in some situations.
And those situations are a process leaking it's own memory space.
You need to first manage to send code to be executed in the memory space of something containing the interesting information to be able to get it, you can't do it from your own process.
(e.g.: Google's Project Zero managed to exploit a non-standard kernel setting that allow you to send eBPF - the bytecode used by modern packet filtering - to a JIT that will run it in-kernel. It's in-kernel software access in-kernel data. You get what you deserve for inviting user-supplied code into your kernel).
On the other hand the Intel CPU flaw allows you around the boundaries that are normally guaranteed by memory protection.
AMD does not have the read-kernel-memory flaw but it does have the read-other-userland-process-memory flaw.
I'll have to re-read the google publication, but I was under the impression that a process can only leak it's own memory space.
(because that one is just about out-of-bound accesses).
The javascript would need to somehow convince your ssh-agent to run some code in its address space to successfully extract the keys.
Basically each process has a different memory map.
Some addresses maps to its own data (for obvious reasons).
Some addresses maps to kernel stuff (so it can call system calls : filesystem accesses, etc.)
There's no address that the Javascript could attempt to read to trigger anything dependent on the ssh-agent.
It can only access addresses that refer to the data of the browser executing it (or more precisely, the current browser process - in case of multi-processing browser like Google's Chrome, or like the post-WebExtentsions-only-no-XUL FireFox's Electrolysis. It won't be able to even see other tabs: there's no memory address that would point to that content)
The only way the Project Zero proof of concept worked was by using a non standard setting to send eBPF (the bytecode used by modern packet filtering) into a JIT that run-it in-kernel (so basically it's an in-kernel process that leaks its own in-kernel data, and you get what you deserve for allowing user-supplied (byte-)code to run in-kernel).
And according to the various docs, the mitigiation against these forms of attacks is rather trivial.
the Intel CPU-specific flaw is an entirely different can of worm.
Most crucially, the mitigation against it comes at a ginormous performance cost.
Basically, each time your app calls into the kernel (e.g.: calls the filesystem to read something from a file), the kernel needs to flush itself out of the accessible memory. On Intel's CPUs, each system call will suddenly come at the same cost as a whole multi-processing switch, even if all happens within the same process.
Each single system call now comes with a craptastic performance hit.
Intel saying that it won't affect significantly average end users ? (Well in the same way the pentium floating point didn't affect them ?)
Well, maybe average users that only use their machine to surf Facebook. They have been running machine way much powerful than needed any way (very seldom do they have any core saturated at 100% use), so they simply won't be noticing the ~30% performance hit. (Who care if their web page loade in 50ms or 100ms ? It's twice the speed, but still under the noticeable threshold).
But for lots of power users (e.g.: gamers) that performance hit is going to be painfully noticeable.
It's going to show up in benchmarks.
It's going to show up in CPU intensive tasks.
It's going to drive a bit some of the market choices.
About the only truly users who won't be affect that much, is scientist running computations that mostly do number crunching (not much kernel switching involved).
Yeah so the fact that some obscure ARM64 demo board that hasn't seen that much actual real-world deployment (*) happens to be made by AMD, means that suddenly everybody must lose confidence in all x86-64 hardware, not only Intel's (which is totally affected by the security shit storm) but also AMD's (whose AMD64 is immune to the actual security leaking exploit. It's not affected by the security shit storm. It's just affected by some proof of concepts where an application can leak it's own memory space) ?
While technically, the words of Intel aren't completely wrong (yup, there exist an obscure chip made by AMD that is affected), it's completely misleading: they want to make you think that it's affecting all manufacturer across the board similarly. It's not. Most of what AMD produces, all the chips you might be thinking about when thinking of AMD (i.e.: the AMD64 chips that make a sizeable chunk of AMD's production, and nearly all of their CPU production), they are not affected.
---
*: honnestly, are there any significant number of machine shipped with Opteron-A ? I mean actual servers deployed in production widescale, not some SBC sold in small quantity to people wanting to experiment with the tech.
They are affected, but not by Meltdown but by Spectre
To expand :
The whole shit storm affecting Intel, is about boundary violations.
That means kernel information leaking into user-land software.
Intel CPU are affected by this (they check access rights much later on, at a point where a lot has happened and that "lot" can be carefully timed and analyzed to leak information out of the kernel space). It allows to have information cross the boundary between kernel and users-space.
AMD CPU are not affect by this (they check access rights ealier, at a point where not much has happened yet). Yes you can also do timing to guess stuff from speculative execution, BUT you are shut out of the kernel space. You can only user this to have one process leak its own memory space. You cannot use this to get things from the kernel into some javscript code, the CPU will block access to early for the attack to actually work.
That is still a pretty serious flaw
Yeah, I'm sure a user-land process being able to leak it's own memory space is a serious flaw... Yay!...
(The only way Google could even demonstrate it, is by enabling some non-standard kernel setting that let you sent eBPF (the byte code used by the packet filter) into a JIT which will run it in-kernel. Thus in-kernel process has access to in-kernel memory space. And you get what you deserve for inviting user-supplied code to run in-kernel)
Yes, you can also time stuff to get information from speculative execution on AMD CPUs.
Except that, due to better security hardware implementation you CANNOT use this to get information accross the kernel fence straight into user space.
With Intel, you end up with a situation where some Javascript code (demo'd at CCC) running in one of your browser tabs could be leaking information straight out of your kernel.
What about my Commodore 64?
In all seriousness :
- old, in-order, non-pipelined CPU like the 6502 in your good old trusted C64 don't do speculative execution and thus aren't affected specifically by such exploits.
but:
- your 6502 doesn't do any form of memory protection : any piece of software can access any part of the whole system (because poking weird memory location is how you control the hardware on such old system) so any software has full access to anything.
So you C64 is leaking sensitive information.
(Later 68k motorola CPU (68030 and up) eventually started to include an built-in MMU to protect memory access, and thus later Amiga machine featuring them (A2500/30, A3000) can be made imune to OS information leaking into userland. That would the first Comodore hardware - vaguely remote cousin of your C64 - to do so)
Yup, i'm giving a technical answer to a joke.
Basically :
AMD checks access rights first and if rejected nothing much happens.
Meaning no leaks from kernel information into user-space running software.
- Google only demonstrated a in user-space software accessing its own in user-space info.
- And by using some non standard settings, it's possible to give bytecode to that kernel, and that piece of in-kernel software will access its own in-kernel info. (But you're already on the other side of the kernel fence)
Nothing gets accross the kernel fence.
Intel checks access rights much later on. By that time quite a lot has happened (e.g.: things could have been loaded in the cache, etc.). By measuring those things, you can deduce information that you should not have access to.
It means that a user-space software could end up getting sensitive information that normally should stay in-kernel.
These subtle timings of cache enable you to get information accross the kernel fence into user-land.
To mitigate these, each time a user-land software calls into a kernel function (e.g.: filesystem access), the OS needs to flush all it's space from the accessible space. This comes at a big performance cost.
If you dig into the details :
AMD actually don't violate boundaries.
As in their LKLM post, they do the access rights checks before anything else, and if rejected nothing much happens that can be timed.
Meaning there's no leaking of kernel information into user-space programs.
The only thing that Google successfully demonstrated is :
- leaking some users-space's program own information (yay!...). There's not much boundary violation here.
- using some non-standard linux kernel settings, to send eBPF (the bytecode used by modern packet filtering) to a JIT that will execute it in kernel. You end-up with in-kernel code being able to leak its own in-kernel information. That might give possibility to create some scary constructs, but ISN'T a violation of boundaries (you're already on the other side of the kernel fence) and requires non-standard settings (which basically amount to giving possibility to execute user-supplied (byte-) code in-kernel. So you basically get what you've deserved for inviting users into your kernel)
On the other hands Intel CPUs do violate boundaries :
It does quite a lot before eventually deciding to kill the invalid access.
All this "lot" are things that can be measured afterward, meaning that information from the kernel can be leaked into the user-app.
Doesn't affect AMD64
The horrible leak that gives access of kernel information to any userspace software that was revealed yesterday doesn't affect AMD64 :
AMD processor reject invalid access much earlier in the pipeline and nothing much happens before that point (e.g.: loading into cache) that could be measured by timing, etc.
In the google paper, they are abusing a different set of anomalies were an application end's up reading it's own memory (yay... ). That *could* be affecting AMD64, but :
- it's only an application in user-space accessing it's own in user-space memory.
- by enabling a few non-standard kernel settings, you end up with a situation where you can send eBPF (the bytecode used by modern packet filtering) to a in-kernel JIT, and it's execution will end up with some in-kernel code reading its own in-kernel memory.
The main big difference, the take-home message:
- on Intel CPU, you have a violation of boundary separation : an end-user application could access information leaking out of the kernel.
- on AMD CPU, this does not happen : you only access information on the same side of the separation boundary.
Or in other words :
- On Intel are in deep shit right now. They need a serious circumvention around it. It means context switch - each time a software calls a system call (e.g.: to access the file system) - the OS needs to flush out all the sensitive information to make them unreachable by the exploit. The end result : massive performance hit.
This is more of a server attack and a web host attack.
No, it's not specific to web servers.
They do use web servers as an example of where the exploit might be applied, but it's not specific.
Basically, this exploit allows to abuse the way speculative execution is done to leak information out of the kernel space into the user space.
(And there are presentation at the CCC of successful abuses done... in Javascript. In a browser).
For more details :
most modern CISC processors (Intel - except for Atoms and Xeon Phi - AMD, etc.) are pipelined and do out-of-order execution.
Executing a CISC instruction requires several steps (micro-ops) and for performance reasons, they keep several instruction in flight (Once instruction A goes out of step 1 and into step 2, you can try already pushing instruction B into step 1).
To gain even more performance, CPUs try to be clever about this (instruction B actually needs results of instruction A, so it needs to wait. But the next instruction C actually can already be started, it doesn't depend on anything still in the pipeline).
Bordering on crystal ball-clever (the next instruction B is a conditional jump. But it looks like a loop, so there's a high chance that it will jump back and repeat. We might as well start working back on instruction A, in case we are correct about this jump).
That's speculative execution : working in advance on stuff that might not even be needed.
(Sometimes, you end up needing to bail out of your speculation, throw the work away and restart because you got your crystal ball wrong. But it's better than just sitting there waiting).
now about memory :
any modern processor worth its salt has memory protection, meaning it handles access rights : Which process can read-write which virtual addresses ?
Usually, sensitive information in the OS is shielded away from the regular software.
On a modern Linux, you can't crash the whole system by writing junk at the wrong address, like you used to do in the old MS-DOS days.
If your software attempts to read something out of the system, the read attempt will be rejected.
the exploit relies on how these both play together.
It happens to be that, in the case of Intel's processors (but not of AMD's), the step where the memory page is loaded from the DRAM stick into the cache happens before the check if the read is valid.
By the time the Intel CPU does the check and notice that the read is invalid and rejects it, quite a lot has happened.
(Things got loaded into cache, other instructions have started their speculative execution in the pipeline, etc.)
These things are measurable (you can measure the timing of some computation to guess what's in the cache and what's not).
Meaning that it's possible to leak sensitive information, that normally pertain in to the OS and shouldn't be application-accessible, by doing a ton of such speculative-execution and timings.
At CCC there was some presentation of this done in javascript: Technically, your browser right now could be executing some random javascript shit from some shaddy website in one of your background tabs and trying to learn as much from your OS as possible.
Such information could further be used while mounting privilege escalations, or other attacks.
In the specific situation of AMD processors, the check is done much earlier (according to their lklm post) and thus not much else has happened already, and there's not much leak from which you could learn.
I have no idea how ARM64 are affected. (But it might also be the cache getting populated before the read attempts get rejected).
The OS devs patching a security hole in the CPU should not leave them open to a lawsuit when the only way to patch it slows down the performance of the system.
Well, not exactly the only way.
One way is to run the upgraded kernel, which will use the fix to circumvent the big CPU flaw, but will take a massive performance hit.
The other way, is to give "nopti" boot param to this new kernel, which will run it as-as with no fixes, which will leave the performance untouched but which is something you would definitely only do on machine that never ever run foreign untrusted code (which according to TFS, also includes javascript).
OS devs just give you a possibility to circumvent the CPU flaw and are cautious as usual to enable the fix by default (for security purpose) and give an option to disable.
It' still something which is optional, up to the choice of the user (even if by default the devs have sided on the security aspect).
On the other hand, Intel are the one who have delivered a pieces of hardware which doesn't work as advertised. (Or could be made sort-of working if you use a performance-killing circumvention).
I don't know, but maybe he runs an high performance computing (HPC ) cluster.
With compute nodes segregated on a separate network that might not even have internet access,
and certainly not running random javascripts downloaded from random websites.
And in these context, performance matters a lot,
while security is handled in a "perimeter" fashion.
In those cases, it makes sense to have an option to disable the fix.
Playing God with the procreation process is usually a civilization destroying process.
What do you mean by "usually" ?
You have a long list of civilisations all destroyed by the process of "Playing God" with the procreation process ?
Like a dozen of such cases, to illustrate that indeed that's the most usual out-come ?
The only instance of "Playing God with the procreation process" is the development of agriculture over the past couple of millennia (hybridizations, selections of weird nearly-impossible offsprings, agricultural crops being so much different from their nearest natural wild relative to be almost unrecognizable, polypoloidy being common in agricultural crops, etc.) and that has in fac turned out quite successful when you look at the evolution of what meal is in your plate.
Do any of them work well enough?
Myriad's Aliendalvik anrdoid layer on Jolla's Sailfish OS more or less works.
The draw back is that it's still based around the "almost not Java" Dalvik JVM-like JIT engine, (well not exactly. It's Myriad's own variation of Dalvik)
so it's still stuck in the world of Android 4.4 Kitkat (so no support for Android 5.0 Lollipop only apps).
The other draw back is that Sailfish OS it selfs lacks drivers and frameworks for some hardware feature (e.g.: finger print scanners. There's a raw device showing up in /dev/ but that's about it), or doesn't have the necessary wrapper to forward other stuff from Gnu/linux world to Android (e.g.: bluetooth. Sailfish OS has a functioning BlueZ, but no wrapper to provide it with the BlueDroid api used on Android Apps. Meaning that some device work - e.g.: bluetooth speakers are handled by bluez and pulseaudio, and android simply see an audio-out and music correctly plays in Spotify, etc. - but app needing low-level acces don't - e.g.: the manufacturer's app to change the configuration of the same bluetooth speaker doesn't work).
Still it runs the majority of apps I've tried on it, (including common stuff like WhatsApp, Instagram, Skype, Messenger, Firefox, my bank's 2 factor app, etc.)
Jolla also has an Aptoid repository with curated APKs that are known to be compatible with Alien Dalvik (the Netflix version available there does work).
I have no experience with BlackBerry's compatibility layer.
I have no experience with Tizen's layer either, but I've read good reviews.
Regarding Windows, Microsoft never managed to get it to work, hence the change of focus to WSL (Windows Service for Linux - a.k.a.: "Bash in Windows").
The subtle difference, is that in France (and somewhat in other countries such as Switzerland) a substantial part of the movie theater are own by corporations such as Pathe / Guamont. which are also movie studios and movie distributor (i.e.: the whole thing is a lot more vertically integrated).
Meaning it's much more easy for them to negociate the price of the movie ticket, because they are also the distributor of the movie.
it's curious how rarely I see operational .APKs on non-Android platforms.
Jolla's Sailfish OS,
Samsung's Tizen,
and Blackberry
(and of course TFA's ChromeOS) :
all have Android compatibility layers.
Microsoft Windows made an attempt but didn't succeed. (WSL is what they managed to salvage out of the remnant of their failed attempt).
This whole thing is crap.
Will it be perfectly efficient ? For sure, not.
(I mean even the Palm/HP's Touchstone surface induction system, which - unlike the Qi system mentioned in the summary - uses magnet to better align the phone with the induction surface, isn't very efficient neither, despite being as close to the emitter as possible)
Will it be a tiny bit better than plain blasting from a globally diffusing antenna ?
Sure, it's going to be a tiny bit better.
It’s surprising the FCC approved it.
FCC's (and similar body is other jurisdiction) only job is to regulate things which might be dangerous and/or damage or disturb other radio equipment.
They don't give a damn if it makes sense economically or in terms of efficiency.
I remember reading about this years ago, and was under the impression that this had been fixed by browsers filling the form fields in the UI, but not in the DOM, until the user explicitly selected one of the fields in the same form.
That's the case in Firefox :
- you need to click on either the username or password field to get a pull-down menu that gives you information about the login, and gives you a selection of passwords saved in the manager.
Also, with most browsers you get extensions like Block Origin, AdBlock Plus, etc. which are going to block most common advertisers.
And extensions such as Privacy Badger which is going to block most common tracker.
And specifically in Firefox (because it requires to either have the new additional extensions that they've added to web extensions to enable this kind of software in the latest firefox, or to have the XUL API in the long term support version) you can also have NoScript, which is going to block all non-explicitely-authorised JavaScript (so tracker missed by the blacklists of UBO, ADP, etc. are blocked anyway), and provides additional alerts against cross site scripting (XSS).
Remember: just as you never fuck without condom, you never surf without your security extensions.
A bigger vehicle like a truck mean more room, and thus more battery.
I wouldn't be surprised if some of them came in "200kWh battery" variations.
And I bet the semi truck models will be named model
- model H
- model Zero
- model T