At the end of the day, you are fundamentally tickling the cache and timing the resultant reads to try to determine the content of that cache.
Correct.
Is there ANY reasonable way to "read" the contents of said cache and determine what context a blob of data means?!?
By using the value you read to trigger another read somewhere else and tickle even more cache timing. You want to trick the CPU into doing something like;
var x = big_array[ (*pointer_to_sensitive_byte) * cache_block_size ];
Then you measure the cache timing of each block of your big_array. And repeat the process for every pointer you want to read.
Beyond trial code that is ALL based on the original POC distributed by virus vendors, etc. there is NO known implementation in the wild.
The original Spectre / Meltdown flaws were separately discovered by multiple researchers at the same time. Do you still feel safe?
This requires the virus to be running ON your fucking computer!! If you are running ANY virus on your computer, you're hosed.
Javascript, Cloud VM's, Untrustworthy phone apps. Do you personally audit all the code that's running on "your" computer?
for the forseeable future ANY virus on your system is about 28Giga-times more likely to be a standard, run-of-the-mill virus
Quite likely, since a patched machine should be less vulnerable, and if you are un-patched there are lots of other vulnerabilities that are easier to exploit. Security is like playing whack-a-mole, if there's just one flaw that you don't fix, you've failed.
Since this detail was missing from the summary; Browsers have limited access to precise timers as a meltdown / spectre mitigation. Web assembly threads might give attackers a way to precisely measure time intervals by executing tight loops in another thread.
Another probably relevant thought. Google recently added the capability to upload your developer signing key, so they can produce apk's with irrelevant assets stripped out. I assume that this feature causes problems for people trying to share apk's between phones. Hence the need to add some extra data to a stripped apk to test compatibility.
Android used to use jar signing, which adds a file of signatures to the zip file. Then they build their v2 signing process, which adds a new block to the zip file between the compressed contents and the directory listing, signing the file hash of the rest of the zip file, directory listings and everything.
Now when you publish to the play store, google are inserting another signature into this v2 signature data block, indicating that this apk was published.
AFAIK this will simply extend their default "play store apk's only" detection to sideloaded files.
Of course it opens the possibility of sideloading an old vulnerable version of an apk...
There's a huge amount of complexity in a modern x86 - x64 based CPU around decoding instructions and detecting where work can be done in parallel. Part of the Itanium design required shifting a bunch of complexity into the compiler.
I can imaging that in the HPC space, where you really care about how fast this single loop is running, it makes sense to invest the engineering effort to improve the compiler. But that work had not been done.
It's easy to sell a CPU that will run your existing binaries faster. It's hard to sell a CPU that will require massive investment on your part to recompile *everything*, with a compiler that doesn't exist yet, in order to see any benefit at all.
Right, each of the variants use that same model; code that is executed speculatively, reads from memory. Your code can see some side effect, and work out what values are in that memory. To extend that simple description slightly to the currently known variants;
Meltdown (CVE-2017-5754). Speculatively executed code can bypass features of Intel CPU's that would normally prevent you from reading the kernel memory of the operating system. The workaround to this problem required changes to how the kernel swaps from "user mode" to "kernel mode", making this process much slower.
Spectre-V1 (CVE-2017-5753). Untrusted code, like JIT compiled Javascript, running inside the same process as trusted code, speculatively executes a read from an array that's out of bounds. This can read any memory that the trusted process can normally read. The linux kernel includes a JIT compiler, so you could use this flaw to read any memory from the kernel. A work-around for this is specific to each program that combines trusted and untrusted code and would probably make every read from an array slower.
Spectre-V2 (CVE-2017-5715). This one is hard to explain in a simple way, but I'll try. For some types of assembly branch instructions, you can train the CPU into branching somewhere the program wouldn't normally go. You use this to trick a trusted program into speculatively reading it's own secrets from memory (which it does normally have permission to do). Then your program can see the effects of this execution. The trusted program could be any another program, the OS kernel, or even running in another VM. It just has to be running on the same physical CPU. A work-around can be built into every compiler, by avoiding using these assembly instructions in every trusted program.
Note that you can combine Meltdown & Spectre-V1 so that Javascript can read from kernel memory. Lots of discussions of these issues have been very murky and confusing, often getting the specific details mixed up. Like which issue can be used to read from the kernel, and which of Intel and AMD is vulnerable.
increase of up to 146% in the compressive strength, up to 79.5% in the flexural one, and a decrease in the maximum displacement due to compressive loading by 78%... 88% increase in heat capacity... decrease in water permeability by nearly 400%... reduction by 50% of the required concrete material while still fulfilling the specifications for the loading of buildings.
Google has some scope to discriminate in favour of "underrepresented" groups and still fill a room with talented people. But you can't "fix" the entire employment sector this way. Even if everyone is given the exact same opportunity to work in this career, doesn't mean that everyone who ends up choosing this work will represent the same breakdown as the entire population.
I'm not saying that the current environment is giving people the same opportunities, and I would support measures to improve that situation. But blindly discriminating against talented people based on them being white males isn't the answer.
Because new money also contributes to economic activity and inflation. Yet economics textbooks completely ignore the capacity of banks to create that additional spending power out of nowhere. Or suggest that government surpluses will magically make the economy grow, when the opposite is true. Trade imbalance also explains why Germany is doing so well, while Greece is doing so poorly.
Every boom is accompanied by unsustainable growth in bank lending, every collapse linked to a reduction in money creation. The best thing our failing western economies can do is boost government spending, while simultaneously winding back bank lending. We will keep having a series of financial crises, until we drastically change the way we create money.
For more detail I suggest you read the work of Steve Keen.
A "good" economics book? Here's a better money equation for you; Income = Expense = existing money * velocity + bank lending [+ government deficit + trade surplus].
If passwords have been salted, every password must be attacked separately anyway.
To put this in plain english, leaking 4 characters of the password might reduce the attack from something google couldn't do, even with all of their available CPU's, to something you can easily do on a single raspberry pi. That's the difference in computational complexity we're talking about here.
Yes, obviously this requires a data leak, and breaking the "encryption" method on the stored password fragment. But that's why we hash passwords anyway.
Lets assume your password is made up of random characters from the entire 90(ish) printable ascii characters. An 8 character password has a 1 in 10^15 chance of any guess being correct. A 4 character password is only 1 in 10^7.
Chances are that your password doesn't use the entire character set, and probably contains a word to make it more memorable. So that the remainder of your password is partially predictable from the first four characters, which is even worse.
Sure you'd probably have to hack the password cracker's code to work with these prefixes, but that shouldn't be too hard.
According to the stats page, 0.33% of steam users are running linux, mostly Ubuntu. Personally, I'm running steam on debian.
Buying a new machine to run steam might be a big ask, but support for running steam on linux is appreciated by those of us that want to play games on our favourite OS.
It's also likely that those 63 interventions were because the car was *too* cautious. For example, around construction zones.
I remember hearing one anecdote. Workmen were moving around their vehicle, inside the border of traffic cones. The car was predicting that they might step out in front, so it just didn't move.
Sounds like just about every failed IT project. Rush to market, ignore test failures, probably a thermocline of truth.
From what we've been hearing, somebody in the chain of command between the inattentive driver and the CEO, deliberately created this situation and should be charged with manslaughter.
I've been following debian testing for a while now, and my click-pad mysteriously changed from clicking in the corners to multi-finger gestures. Trying to use Libreoffice without knowing how to right-click anymore was very frustrating. Took me ages to work out which keywords to google and where the setting was to change it back. Why was this option not in the default settings dialog? Even hiding behind an advanced button?
Yes they do, and now clang can produce that debug info in a format that visual studio can read. That was a key piece of development that allowed this change to happen.
but with the names of the functions of the system libraries and their parameters
Any developer should be hiding platform differences in isolated code that is only compiled for that platform. If you aren't touching that kind of code, your patch shouldn't break any other platform. The problems of supporting multiple compilers can be much more subtle than that.
C++ is a complex language, with many small behaviour details either left up to the compiler to define or deliberately left undefined. If you are restricting your code to behaviour that is well defined, you should be fine. However, different compilers sometimes interpret the language spec differently, and exploit the freedom that undefined behaviour gives them in different ways. Code that works fine when compiled with MSVC, might raise an error when compiled with clang, breaking the build for other developers. Developing any large C++ software, and supporting compiling it with multiple different C++ compilers, adds overhead to the day-to-day development of that software.
The point is that chrome dev's can write *and debug* code using visual studio if that's what they prefer. While developers for all supported platforms can submit patches that are less likely to break when compiled for another platform, as they are using the exact same compiler.
Writing C++ code that works with microsoft's compiler on windows and clang on other platforms adds significant overheads. Microsoft has historically been slow to implement new C++ features completely and correctly in the past, making it much more likely that developers will submit patches that fail to compile on windows.
Slashdot Mirror
Ridiculously difficult to implement.
Once.
At the end of the day, you are fundamentally tickling the cache and timing the resultant reads to try to determine the content of that cache.
Correct.
Is there ANY reasonable way to "read" the contents of said cache and determine what context a blob of data means?!?
By using the value you read to trigger another read somewhere else and tickle even more cache timing. You want to trick the CPU into doing something like;
var x = big_array[ (*pointer_to_sensitive_byte) * cache_block_size ];
Then you measure the cache timing of each block of your big_array. And repeat the process for every pointer you want to read.
Beyond trial code that is ALL based on the original POC distributed by virus vendors, etc. there is NO known implementation in the wild.
The original Spectre / Meltdown flaws were separately discovered by multiple researchers at the same time. Do you still feel safe?
This requires the virus to be running ON your fucking computer!! If you are running ANY virus on your computer, you're hosed.
Javascript, Cloud VM's, Untrustworthy phone apps. Do you personally audit all the code that's running on "your" computer?
for the forseeable future ANY virus on your system is about 28Giga-times more likely to be a standard, run-of-the-mill virus
Quite likely, since a patched machine should be less vulnerable, and if you are un-patched there are lots of other vulnerabilities that are easier to exploit. Security is like playing whack-a-mole, if there's just one flaw that you don't fix, you've failed.
Since this detail was missing from the summary; Browsers have limited access to precise timers as a meltdown / spectre mitigation. Web assembly threads might give attackers a way to precisely measure time intervals by executing tight loops in another thread.
Another probably relevant thought. Google recently added the capability to upload your developer signing key, so they can produce apk's with irrelevant assets stripped out. I assume that this feature causes problems for people trying to share apk's between phones. Hence the need to add some extra data to a stripped apk to test compatibility.
Android used to use jar signing, which adds a file of signatures to the zip file. Then they build their v2 signing process, which adds a new block to the zip file between the compressed contents and the directory listing, signing the file hash of the rest of the zip file, directory listings and everything.
Now when you publish to the play store, google are inserting another signature into this v2 signature data block, indicating that this apk was published.
AFAIK this will simply extend their default "play store apk's only" detection to sideloaded files.
Of course it opens the possibility of sideloading an old vulnerable version of an apk...
Sure, the swift compiler has to strip away a few layers of abstraction first. But swift is compiled using the same LLVM backend as clang.
An SAT solver? Now that could be interesting....
There's a huge amount of complexity in a modern x86 - x64 based CPU around decoding instructions and detecting where work can be done in parallel. Part of the Itanium design required shifting a bunch of complexity into the compiler.
I can imaging that in the HPC space, where you really care about how fast this single loop is running, it makes sense to invest the engineering effort to improve the compiler. But that work had not been done.
It's easy to sell a CPU that will run your existing binaries faster. It's hard to sell a CPU that will require massive investment on your part to recompile *everything*, with a compiler that doesn't exist yet, in order to see any benefit at all.
Yeah, but that's the 19th of January. Maybe if you attempted to enter a date after that, it would revert to 1970....
Right, each of the variants use that same model; code that is executed speculatively, reads from memory. Your code can see some side effect, and work out what values are in that memory. To extend that simple description slightly to the currently known variants;
Meltdown (CVE-2017-5754). Speculatively executed code can bypass features of Intel CPU's that would normally prevent you from reading the kernel memory of the operating system. The workaround to this problem required changes to how the kernel swaps from "user mode" to "kernel mode", making this process much slower.
Spectre-V1 (CVE-2017-5753). Untrusted code, like JIT compiled Javascript, running inside the same process as trusted code, speculatively executes a read from an array that's out of bounds. This can read any memory that the trusted process can normally read. The linux kernel includes a JIT compiler, so you could use this flaw to read any memory from the kernel. A work-around for this is specific to each program that combines trusted and untrusted code and would probably make every read from an array slower.
Spectre-V2 (CVE-2017-5715). This one is hard to explain in a simple way, but I'll try. For some types of assembly branch instructions, you can train the CPU into branching somewhere the program wouldn't normally go. You use this to trick a trusted program into speculatively reading it's own secrets from memory (which it does normally have permission to do). Then your program can see the effects of this execution. The trusted program could be any another program, the OS kernel, or even running in another VM. It just has to be running on the same physical CPU. A work-around can be built into every compiler, by avoiding using these assembly instructions in every trusted program.
Note that you can combine Meltdown & Spectre-V1 so that Javascript can read from kernel memory. Lots of discussions of these issues have been very murky and confusing, often getting the specific details mixed up. Like which issue can be used to read from the kernel, and which of Intel and AMD is vulnerable.
increase of up to 146% in the compressive strength, up to 79.5% in the flexural one, and a decrease in the maximum displacement due to compressive loading by 78% ... 88% increase in heat capacity ... decrease in water permeability by nearly 400% ... reduction by 50% of the required concrete material while still fulfilling the specifications for the loading of buildings.
Google has some scope to discriminate in favour of "underrepresented" groups and still fill a room with talented people. But you can't "fix" the entire employment sector this way. Even if everyone is given the exact same opportunity to work in this career, doesn't mean that everyone who ends up choosing this work will represent the same breakdown as the entire population.
I'm not saying that the current environment is giving people the same opportunities, and I would support measures to improve that situation. But blindly discriminating against talented people based on them being white males isn't the answer.
Because new money also contributes to economic activity and inflation. Yet economics textbooks completely ignore the capacity of banks to create that additional spending power out of nowhere. Or suggest that government surpluses will magically make the economy grow, when the opposite is true. Trade imbalance also explains why Germany is doing so well, while Greece is doing so poorly.
Every boom is accompanied by unsustainable growth in bank lending, every collapse linked to a reduction in money creation. The best thing our failing western economies can do is boost government spending, while simultaneously winding back bank lending. We will keep having a series of financial crises, until we drastically change the way we create money.
For more detail I suggest you read the work of Steve Keen.
A "good" economics book? Here's a better money equation for you; Income = Expense = existing money * velocity + bank lending [+ government deficit + trade surplus].
What is often mistaken for 20 years’ experience, is just 1 year’s experience repeated 20 times.
We know almost exactly how much support there was for gay marriage in Australia, since 80% of people returned the survey form.
If passwords have been salted, every password must be attacked separately anyway.
To put this in plain english, leaking 4 characters of the password might reduce the attack from something google couldn't do, even with all of their available CPU's, to something you can easily do on a single raspberry pi. That's the difference in computational complexity we're talking about here.
Yes, obviously this requires a data leak, and breaking the "encryption" method on the stored password fragment. But that's why we hash passwords anyway.
Reducing your password strength by 10^7 is huge. Even the most intensive brute force search will crack passwords 10 million times faster.
Lets assume your password is made up of random characters from the entire 90(ish) printable ascii characters. An 8 character password has a 1 in 10^15 chance of any guess being correct. A 4 character password is only 1 in 10^7.
Chances are that your password doesn't use the entire character set, and probably contains a word to make it more memorable. So that the remainder of your password is partially predictable from the first four characters, which is even worse.
Sure you'd probably have to hack the password cracker's code to work with these prefixes, but that shouldn't be too hard.
According to the stats page, 0.33% of steam users are running linux, mostly Ubuntu. Personally, I'm running steam on debian.
Buying a new machine to run steam might be a big ask, but support for running steam on linux is appreciated by those of us that want to play games on our favourite OS.
It's also likely that those 63 interventions were because the car was *too* cautious. For example, around construction zones.
I remember hearing one anecdote. Workmen were moving around their vehicle, inside the border of traffic cones. The car was predicting that they might step out in front, so it just didn't move.
Sounds like just about every failed IT project. Rush to market, ignore test failures, probably a thermocline of truth.
From what we've been hearing, somebody in the chain of command between the inattentive driver and the CEO, deliberately created this situation and should be charged with manslaughter.
I've been following debian testing for a while now, and my click-pad mysteriously changed from clicking in the corners to multi-finger gestures. Trying to use Libreoffice without knowing how to right-click anymore was very frustrating. Took me ages to work out which keywords to google and where the setting was to change it back. Why was this option not in the default settings dialog? Even hiding behind an advanced button?
Winbox was insecure by design. It downloaded dll's from the router and ran them.
How were the routers infected? Some already known exploit, or intercepting the devices during shipping? Who knows.
The binaries only need debug info
Yes they do, and now clang can produce that debug info in a format that visual studio can read. That was a key piece of development that allowed this change to happen.
but with the names of the functions of the system libraries and their parameters
Any developer should be hiding platform differences in isolated code that is only compiled for that platform. If you aren't touching that kind of code, your patch shouldn't break any other platform. The problems of supporting multiple compilers can be much more subtle than that.
C++ is a complex language, with many small behaviour details either left up to the compiler to define or deliberately left undefined. If you are restricting your code to behaviour that is well defined, you should be fine. However, different compilers sometimes interpret the language spec differently, and exploit the freedom that undefined behaviour gives them in different ways. Code that works fine when compiled with MSVC, might raise an error when compiled with clang, breaking the build for other developers. Developing any large C++ software, and supporting compiling it with multiple different C++ compilers, adds overhead to the day-to-day development of that software.
The point is that chrome dev's can write *and debug* code using visual studio if that's what they prefer. While developers for all supported platforms can submit patches that are less likely to break when compiled for another platform, as they are using the exact same compiler.
Writing C++ code that works with microsoft's compiler on windows and clang on other platforms adds significant overheads. Microsoft has historically been slow to implement new C++ features completely and correctly in the past, making it much more likely that developers will submit patches that fail to compile on windows.