Google Says Almost All CPUs Since 1995 Vulnerable To 'Meltdown' And 'Spectre' Flaws (bleepingcomputer.com) 269
Catalin Cimpanu, reporting for BleepingComputer: Google has just published details on two vulnerabilities named Meltdown and Spectre that in the company's assessment affect "every processor [released] since 1995." Google says the two bugs can be exploited to "to steal data which is currently processed on the computer," which includes "your passwords stored in a password manager or browser, your personal photos, emails, instant messages and even business-critical documents." Furthermore, Google says that tests on virtual machines used in cloud computing environments extracted data from other customers using the same server. The bugs were discovered by Jann Horn, a security researcher with Google Project Zero, Google's elite security team. These are the same bugs that have been reported earlier this week as affecting Intel CPUs. Google was planning to release details about Meltdown and Spectre next week but decided to publish the reports today "because of existing public reports and growing speculation in the press and security research community about the issue, which raises the risk of exploitation."
I'm not even surprised. (Score:2)
This isn't even surprising that the problem exists in almost every CPU since a long time considering that most CPUs share the same type of logic in order to achieve the best performance. But performance and security often comes into conflict.
Re: (Score:2)
Actually in this case I think "strategy" rather than "logic" is probably a better way of putting it. Everyone uses speculative evaluation to speed things up, Intel just does it slightly more aggressively than other chipmakers and so presents a slightly larger attack surface.
Almost All processors (Score:3)
Re:Almost All processors (Score:5, Informative)
Best I can tell, the only CPUs guaranteed not affected by both are in-order architectures, which many older ARM (and extremely old x86) chips are.
These attacks are a sort of new category of security analysis--realizing that out of order execution can have side effects, and that programs can check for those side effects to leak program state and system memory.
Re: (Score:3)
These attacks are a sort of new category of security analysis--realizing that out of order execution can have side effects, and that programs can check for those side effects to leak program state and system memory.
Not really. Sophisticated security attacks written in ASM have been around for decades. I have a friend who has worked for a decade as a security contractor for federal agencies and they are well aware of this sort of thing. I think what's happened is the knowledge to be able to architect these types of exploits is known to a relatively small group of people that have highly specialized knowledge. Most of the exploits we see these days are effectively script kiddies but in some cases very effect. Back
Re: (Score:2)
Re: (Score:2)
But older architectures has other kinds of security gaps instead. So going back isn't going to help either.
And today we essentially only have ARM and x86 architectures to care about. Sparc is a fringe architecture, so is PowerPC and MIPS, which means that it really doesn't matter if these architectures are impacted or not.
Re: (Score:3)
SPARC, MIPS and PowerPC may be fringe but they are still out there in the fringe for servers and/or supercomputers.
Several CPUs of each architecture were released in 2017.
IBM's POWER chips have supported the full PowerPC ISA for a decade and its performance is very competitive to Intel XEON, if not surpassing.
Oracle (which had bought Sun) closed their SPARC processor group last year though. Fujitsu may still be active.
Chinese Loongson makes MIPS processors at 1.5GHz, but they would need to step it up to com
Re:Almost All processors (Score:5, Interesting)
Spectre is linked to two vulnerabilities: the first one is difficult to exploit and solvable via software, the second one is very difficult to exploit. Spectre allows to read memory from the same process, so it is an issue only for JIT and VM code. Meltdown allows to read memory everywhere.
Re: (Score:2)
The paper appears to claim that Spectre can read memory from a different process, provided it can get that process to do things by giving input to it.
Re:Almost All processors (Score:5, Interesting)
No. Spectre affects AMD and ARM as well (and likely other architectures too).
Best I can tell, the only CPUs guaranteed not affected by both are in-order architectures, which many older ARM (and extremely old x86) chips are.
These attacks are a sort of new category of security analysis--realizing that out of order execution can have side effects, and that programs can check for those side effects to leak program state and system memory.
Spectre is a red herring - there is no known way it can be exploited. Meltdown is far more dangerous and it can be exploited RIGHT NOW with a simple Javascript executed in a browser. Researchers demonstrated a Javascript exploit that uses Meltdown - and there is no telling who has already been compromised. But one thing is sure: non-Intel users have not been compromised.
Frankly, this whole hoopla about Spectre seems like a well orchestrated deflection stunt by Intel PR operations. And your posts smells a bit of sockpuppetry.
Re:Almost All processors (Score:5, Informative)
Frankly, this whole hoopla about Spectre seems like a well orchestrated deflection stunt by Intel PR operations.
I'd caution against a false sense of security, based on one's choice of processor for your personal desktop.
There's no disagreement that "Meltdown" is the greater problem, and affects pretty much any Intel chip still functioning. It's important to remember that it's virtually guaranteed that connect to many servers that uses an affected processor every day. Those of us who maintain cloud infrastructures are particularly unhappy with the situation.
The fact that Meltdown is worse shouldn't distract from the fact that Spectre is bad.
The paper on Spectre [spectreattack.com] is written by a number of people working for a number of organizations, but Intel isn't one of them. It has the following statement:
We have also verified the attack’s applicability to AMD Ryzen CPUs. Finally, we have also successfully mounted Spectre attacks on several Samsung and Qualcomm processors (which use an ARM architecture) found in popular mobile phones
They go on to state they've verified the weakness on x86 using C and JavaScript (+ Google V8 JIT) bytecode.
Much like JavaScript cryptocurrency mining , the fact that something is hard doesn't mean it's not worth doing to those interested, and having browser-based JavaScript exposing data isn't a good thing.
Meltdown can be fixed fairly easily (AMD certainly shows it's possible to avoid the problem). Spectre, however, will be with us for a long time.
Re: (Score:2)
I once had a job with a company contracted to install server farms for the DOD and some other agencies. I had a fairly low level clearance and was hired right away. I was promoted when they found out I had a Solaris cert, becasue most of the server farms were running Sun blade servers with Sparc processors even though intel blades which were faster and cheaper were available.
One day, at lunch, I asked about this, and his comment stuck with me. he basically told me that most of the DOD and other intelligence
Re: (Score:3)
Spectre is a red herring - there is no known way it can be exploited.
Yet.
non-Intel users have not been compromised
So far.
Frankly, this whole hoopla about Spectre seems like a well orchestrated deflection stunt by Intel PR operations. And your posts smells a bit of sockpuppetry.
Intel had nothing to do with it; all three issues were found by Google Project Zero (who didn't name them; GPZ doesn't do silly vulnerability marketing games), and then independently by other researchers.
Note that I'm not trying to defend Intel. I'm an AMD fanboy from way back, and I'd love to see this give AMD a major boost in sales for a few years. But let's not get overconfident. This is a brand new class of attack and few security researchers have focused on it yet. There will be more attac
Re:Almost All processors (Score:4, Informative)
Google has exploited it. Look at Google Project Zero's write-up [blogspot.co.uk] of these bugs. Spectre corresponds to "Variant 1 and Variant 2" in that blog post. You'll see that they successfuly exploit both, the second from a KVM guest.
It is true that Google cheat a little here, by using Linux's eBPF JIT engine (which, I hear, is normally disabled by default). From the blog post:
Re: (Score:3)
No. Spectre affects AMD and ARM as well (and likely other architectures too).
AMD CPUs were demonstrated to be vulnerable to Spectre under Linux only in a non-standard kernel configuration. In the standard configuration, they demonstrated "the ability to read data within the same process, without crossing privilege boundaries."
It's possible that future research will reveal vulnerabilities on AMD CPUs, but as of now, I don't see that one has been verified under the standard kernel configuration. (So don't enable eBPF JIT)
Spectre (Score:3)
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 Spec
Re: (Score:2)
Does anyone know if this will affect PowerPC, SPARC, Alpha, and MIPS as well?
Re: (Score:2)
This seems to focus on branch prediction and the impact of backing the pipeline contents. The error seems to center on taking a branch into privileged memory that is initiated by unprivileged code. Therefore, any CPU with branch prediction is likely suspect.
arm32 versus AArch64 (Score:4, Informative)
32-bit ARM may be safer, because speculative execution is much, much more difficult there.
The program counter is a visible register that can be manipulated by any opcode - an explicit JUMP or BRANCH is not necessary. This makes branch prediction mostly impossible.
Most opcodes are conditional. This dependency between adjacent instructions is also a huge obstacle for speculative execution.
32-bit ARM is mostly in-order for these reasons.
https://www.jwhitham.org/2016/02/risc-instruction-sets-i-have-known-and.html [jwhitham.org]
Re:arm32 versus AArch64 (Score:4, Informative)
:
This attack is a side effect of out-of-order execution. This did not happen to ARM until the Cortex A8 line of processors (Cortex A7 was still in-order). Not to be confused with ARMv7/ARMv8, since Cortex A7 and A8 implement ARMv7.
And yes, even in 64-bit ARM PC is a user-visible register - AArch32 and AArch64 are very similar to each other down to instruction coding, too. The only big thing AArch64 eliminates is conditional execution which ARM found with the Cortex A8 to interfere with superscalar execution. But just because it's harder to speculatively execute doesn't mean it's impossible. It just means you execute the instruction and then evaluate the condition later - if the condition turns out to be false, you retire the instruction without posting the effects to the architectural registers. If the instruction is true, you retire it normally. Either way, you consume the same time (an instruction not executed conditionally on ARM is considered a NOP and only wastes processor time. This fact alone makes it worthwhile to execute all conditional instructions and retire them when the end result of the condition is known - you're using up time anyhow).
Also, I'm sure the Cortex A8 notes which instructions potentially could adjust the PC (the register field of every instruction is well defined, so it's trivial to examine it and determine if it's the PC. In fact, a JMP is syntactic sugar for a MOV, as is RET. They are internally MOV instructions (you'll note that every function ends with "mov pc,lr", which moves the link register (old PC before call) to the PC, thus returning.
Modern thumb interworking though uses "blx" which is branch-to-link-and-exchange because you need to load both the LR and the old CPSR register (which controls the THUMB state), so you return back to the right mode and is the only way if you're mixing ARM and THUMB instructions together (aka interworking).
Re: (Score:2)
These attacks are a sort of new category of security analysis--realizing that out of order execution can have side effects, and that programs can check for those side effects to leak program state and system memory.
They are not new in any shape or form.
https://eprint.iacr.org/2006/2... [iacr.org]
Re: (Score:3)
They didn’t say AMD was vulnerable to Meltdown. Do you have the reading comprehension skills of stone?
Re: (Score:2)
Re: (Score:3)
Yes - but both AMD and ARM are affected by Spectre, which there is NO KNOWN FIX for.
Re: (Score:3)
Spectre is already patched on some ARM processors (note that many ARM processors are not affected by Spectre), while AMD says that it should be patched in the software affected. Since Spectre only refers to leakages of memory in the same process, it is only a problem for JIT and VM stuff (e.g. browsers and their Javascript, wait for a browser update in the next f
Re: (Score:2)
"that it should be patched in the software affected"
That is code for "we cant update the microcode, it *should* be patched in the CPU, but cant be ( and we dont want to say that ), so, hopefully the software can mitigate".
Re: (Score:2)
If the defect is in the microcode and they patch it in software, isn't it still vulnerable? Doesn't seem like it would be difficult to undo or work around the software patch to access the original defective microcode.
Spectre vulnerability vs. bad design (Score:3)
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
Re: (Score:3)
Re: (Score:3)
Re:Almost All processors (Score:5, Informative)
Please read the article. From it:
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.
Scale of the attacks. (Score:4, Insightful)
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.
Re: (Score:2)
At least not with the attack style that works on Intel processors, but I wouldn't be surprised if there are similar methods that works on AMD processors.
Re: (Score:2)
Yes, because Spectre = Meltdown. Try reading.
Wrong. They are the same class of bug around speculative execution but they are not the same thing.
Re: (Score:2)
Re: (Score:2)
My bad. Missed your sarcasm. ^_^;
Re: (Score:3)
My bad.
Are you sure you're on the right forum? This sounds suspiciously like owning up to an honest mistake and moving on. That's not going to cut it around here.
Re: (Score:3)
Damn right, that's not how you play /., you insist that you're right and make a complete ass out of yourself. You can't just go and say "my bad", that's not allowed here.
I so unsubbed to your channel!
Re: (Score:3)
https://arstechnica.com/gadget... [arstechnica.com]
Re: (Score:2)
Every modern processor has unfixable security flaws
Heh. That phrasing is debatable. Release a better processor and the "unfixable" security flaws will have been fixed. ;)
Re: (Score:2)
Probably more like "not possible to fix fully with software".
Re: (Score:2)
"“Meltdown” and “Spectre”: Every modern processor has unfixable security flaws" https://arstechnica.com/gadget... [arstechnica.com]
Which makes you wonder if this is actually a flaw. A flaw is where something does not work the way it was designed to work. The fact that every modern processor has the same vulnerability suggests that perhaps this was designed into them at some point. I have no evidence that this was designed in, but one should at least entertain the possibility that it was.
Re:Almost All processors (Score:4, Insightful)
Of course it’s a flaw. It’s an unintended side-effect of speculative execution.
Re: (Score:2)
Re: (Score:2)
Yes, it really boosts your sales, especially internationally, when the press tells everyone your CPUs are insecure crap. That's why the Intel boss sold his shares in time because he knew that it's going to be a big boon for his company when everyone learns about the problem.
People, I love a good conspiracy theory like the next guy, but try to create some that are at least plausible.
Re: (Score:2)
Yes, it really boosts your sales, especially internationally, when the press tells everyone your CPUs are insecure crap
Well, a lot of people have to buy new CPUs now...
Re: (Score:2)
Really? Which one? The one from your competitor that allegedly does not have that bug?
Re: (Score:2)
Really? Which one? The one from your competitor that allegedly does not have that bug?
Possibly, yes. Another possibility is to replace it with a new intel CPU where the bug is fixed, or at least a model where a software fix can be implemented with minimum performance degradation.
Re: (Score:2)
Re: (Score:2)
Yes, it really boosts your sales, especially internationally, when the press tells everyone your CPUs are insecure crap
It actually might: many makers (<cough>Apple</cough>) only buy Intel chips, and I wouldn't be surprised if a lot of folks buy a new computer in the (mistaken) belief that will have an updated CPU that fixes the bug.
Few consumers understand the lead time for hardware to go from an engineer's workstation to fabricated hardware. I wouldn't expect an Intel chip that won't "Meltdown" until 2019 at the earliest.
That's why the Intel boss sold his shares in time
The problem (for the prosecutor) is proving to the Jury that it was insider trading. (And t
Re: (Score:2)
Hanlon's rasor [wikipedia.org] applies pretty well here.
We can't even design a car with a few thousand parts that doesn't have unintended side effects.
The idea a machine with billions of transistors won't have unintended side effects is comical at best.
Processor eratta are maintained by every chip maker -- from the lowliest 4-bit microcontroller all the way up to beasts like Ryzen. This particular problem just happens to be unusually bad, and in a place that can't be fixed with microcode.
Re:Almost All processors (Score:5, Insightful)
A hardware version of PRISM? https://en.wikipedia.org/wiki/... [wikipedia.org]
Room 641A Inside https://en.wikipedia.org/wiki/... [wikipedia.org] most computers?
It was interesting how much of the NSA ANT catalog https://en.wikipedia.org/wiki/... [wikipedia.org] connected to a computer rather than was able to work internally on a CPU as shipped?
Is the world missing the other part of the CPU catalog thats still doing collect it all missions?
Re: (Score:2, Interesting)
...The fact that every modern processor has the same vulnerability suggests that perhaps this was designed into them at some point. I have no evidence that this was designed in, but one should at least entertain the possibility that it was.
Perhaps we should entertain the possibility that the revelations of Edward Snowden scratch the fucking surface as to the deceptive power and control that the US government holds over US corporations.
I'd say there's more than enough evidence to suggest this is no fucking "flaw". In fact, the timing of it all tends to suggest the Clipper chip program didn't just go away in the late 90s; it was superseded.
Re: (Score:2)
Re:Almost All processors (Score:5, Informative)
I just read the papers and it's actually a fascinating, and deceptively simple method. Out-of-order execution and execution prefetching causes a CPU to pre-execute instructions that are later on in the chain. If my program performs a divide-by-zero, which will cause an error when it happens, instruction pre-fetching and out of order execution has already in whole or part executed the instructions that happen after the error. So, you write your program to do this:
Something legal
Fork
Child:
Divide by Zero
Read of illegal memory
Parent:
Wait for child to crash
Read the prefetch cache to see what the out-of-order execution put in the cache when it read the illegal memory
In case that's not clear, a program forks. The child process induces an error, but after the error it has an instruction which would not normally be allowed, such as reading a portion of memory it wouldn't normally be able to. Out of order execution will already have begun performing the instruction, and because it doesn't have as rigorous controls on it, it actually reads the memory into the cache. This wouldn't be an issue, except there are ways to determine what a prefetch instruction resulted in. So the parent process waits for the child to crash and then it uses those instructions to determine the results of the prefetch which means you have just bypassed memory protection.
Re: (Score:3)
Re:Almost All processors (Score:4, Informative)
The attack checks which rows of cache got evicted by reading across a large array, requesting behavior by another process, and then re-reading the array timing how long each read takes. Each iteration of the attack reveals a byte of memory by identifying which cache row it affected.
Re: (Score:3)
Re: (Score:2)
Well, there was the NexGen, but I have only seen it being sold in a shop once - with the motherboard - and when I've returned with cash it was already gone.
Re: (Score:3)
the AMD K5 was AMD's first processor and released in 1996
I know I had an AMD 386DX/40. Intel was pretty expensive back then, and I couldn't have purchased the processor for what I paid for the whole full tower unit. Okay, so it was the Am386 [wikipedia.org]. You likely recall the K5 release name because they renamed the 586 the Pentium and the 686 the Pentium Pro, and they sued AMD and Cyrix for using the numbers 486 and 586. Ultimately Intel lost. However, to shield itself from lawsuits, AMD had no choice but to name their processor the K5. Also, Cyrix (now Via) named the
Re:Almost All processors (Score:4, Informative)
K5 was the first totally in-house designed AMD CPU and one of the first to do out of order execution, which is what these bugs exploit. Whether it is actually vulnerable would have to be tested.
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:3)
Oh, for FFS, at least get your facts straight.
K5 was AMD's first processor? I must have imagined a whole heap of their processors which I owned and used before that one... And meltdown STILL doesn't affect AMD, all we have on that front is speculation from intel and their fanboys who wants to paint everyone else with the same tar brush.
I should have said the AMD K5 was AMD's first in-house processor. The whole history is right here [wikipedia.org]. No fan boi nonsense just facts. If you don't like facts, I can't help you.
They did not test AMD or ARM (Score:3, Informative)
At the time of writing, Google believes that "every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013)" is affected by Meltdown. Google says it verified Meltdown only against Intel CPUs, but not ARM and AMD. Nonetheless, Intel has a market share of than 80% on desktops and more than 90% on the laptop and server markets, meaning that a large number of desktops, laptops, and servers are affected.
Re: (Score:2)
AMD seem to think they're not affected by Meltdown: [lkml.org]
BTB it is almost certainly this email, sent on 26 December, which led to the Meltdown vulnerability being made public [twitter.com], causin
Re:They did not test AMD or ARM (Score:4, Informative)
No, they did test their Meltdown code on AMD and ARM but were not able to reproduce it on the chips they tested on.
That does not prove that a Meltdown-like attack on AMD or ARM is impossible, either on a different chip they did not test on or with a tweaked version of Meltdown.
From the actual article ("meltdown.pdf"):
Re: (Score:3)
Re: (Score:3)
Spectre, which is more of a generalized class of attacks, but more difficult to implement, impacts Intel, AMD, and ARM as per the original spectre paper. https://spectreattack.com/spec... [spectreattack.com], from which I quote:
Hardware. We have empirically verified the vulnerability of several Intel processors to Spectre attacks, including Ivy Bridge, Haswell and Skylake based processors. We have also verified the attack’s applicability to AMD Ryzen CPUs. Finally, we have also successfully mounted Spectre attacks on several Samsung and Qualcomm processors (which use an ARM architecture) found in popular mobile phones.
and
Unlike Meltdown, the Spectre attack works on non-Intel processors, including AMD and ARM processors. Furthermore, the KAISER patch [19], which has been widely applied as a mitigation to the Meltdown attack, does not protect against Spectre.
References:
Spectre https://spectreattack.com/spec... [spectreattack.com]
Meltdown https://meltdownattack.com/mel... [meltdownattack.com]
Re: (Score:3)
The paper also appears to insinuate that RISC-V and MIPS might be vulnerable as well.
RISC-V is so new it's not widely deployed, but MIPS... well, that's in most routers.
Better link and description than story (Score:5, Informative)
Meltdown breaks the most fundamental isolation between user applications and the operating system. This attack allows a program to access the memory, and thus also the secrets, of other programs and the operating system.If your computer has a vulnerable processor and runs an unpatched operating system, it is not safe to work with sensitive information without the chance of leaking the information. This applies both to personal computers as well as cloud infrastructure. Luckily, there are software patches against Meltdown.
Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets. In fact, the safety checks of said best practices actually increase the attack surface and may make applications more susceptible to Spectre. Spectre is harder to exploit than Meltdown, but it is also harder to mitigate. However, it is possible to prevent specific known exploits based on Spectre through software patches.
Re: (Score:3)
There's a pretty good summary in the XenProject Security Advisory [xen.org]:
Re: (Score:2)
Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets. In fact, the safety checks of said best practices actually increase the attack surface and may make applications more susceptible to Spectre. Spectre is harder to exploit than Meltdown, but it is also harder to mitigate. However, it is possible to prevent specific known exploits based on Spectre through software patches.
This paragraph, which you copy-pasted from meltdownattack.com, is not explaining much. I would go as far as to say that it's jackshit. Just read the linked research paper.
Re: (Score:2)
Which is why I provided that URL. None of the clickbait articles had links to the research paperS (plural, MF'er).
So...you're welcome newbie. Now GTFO my lawn.
Re: (Score:2)
>> Just read the linked research paper.
Which is why I provided that URL. None of the clickbait articles had links to the research paperS (plural, MF'er).
So...you're welcome newbie. Now GTFO my lawn.
I used singular, because the topic was Spectre, so I only referenced the Spectre paper [spectreattack.com].
And "newbie"? Who uses that, anymore? I remember it being quite the term, circa 1998.
Re: (Score:2)
It is verified "safe" by the compiler statically at compile time.
Static analysis is nice and all, but can only do so much. There are whole categories of problems that static analysis tools are blind to. For example: Spectre. Anything below the language layer, or any sufficiently clever runtime funny business won't be detected (Spectre is both).
Re: (Score:2)
Rust does have runtime checks. Where did you get this nonsense that it didn’t? How could a compiler do bounds checking for buffers allocated at runtime with an unknown-at-compile-time size?
Thios one is CPU specific (Score:3)
Sigh, did anyone actually read the spectre paper;
Exploiting Indirect Branches.
The bit about execution beyond software checks is explaining a specific detail about memory side effects. The above section builds on that concept to show that you can induce these memory side effects by tricking the branch predictor to execute existing code in an unexpected way.
Okay, to go into more details :
there are two things that are call spectre, which are both based around speculative execution.
The first one, which gets around software check, to which every single deeply-pipelined/out-of-order CPU that does speculative execution (lots of vendors, some as long back as mid 90s), and which is basically still "speculative execution working as intended", is the one I've described in my post.
That the one to which every piece of software running on nearly any CPU (except perhaps o
Easy Fix (Score:2, Funny)
Just patch all the CPUs so they process things introspectively, with a glass of wine and some light jazz.
Ok, now what? (Score:2)
What are we supposed to do? Have you seen the price of Amiga and Atari ST computers on eBay? Not to mention that there's nowhere near enough to supply the whole planet!
Has anyone started working on an OS/9 port of Firefox for the Color Computer 3 yet?
Re: (Score:2)
You could wrap all your computers in tinfoil. If it works for mind control rays on your head it might for this.
Re: (Score:2)
What are we supposed to do? Have you seen the price of Amiga and Atari ST computers on eBay? Not to mention that there's nowhere near enough to supply the whole planet!
My Amiga doesn't have a MMU, you insensitive clod! Luckily I have AMD processors, on which you can mitigate these attacks. Now if I could just figure out how to disable their equivalent of the management engine
Re: (Score:2)
Looks like I'm going to have to drag my Quadra 700 out of mothballs. Anybody know what the latest version of System 7 is? Just hope my 320MB external hard drive isn't full....
Hey, anybody got a 56K modem I could borrow?
Re: (Score:2)
Are you saying that the old PowerPC Macs are immune to these two problems?
Reaction? (Score:2)
Re: (Score:2)
486 (Score:4, Funny)
Re: (Score:2)
Time to bust out my 486!
Don't have to go back that far. Bonnelle and Saltflat (first and second generation) Atoms are strictly in-order. No speculative execution. Just move your server loads to clusters of 2nd generation eeepc's!
Vulnerability comes down to race condition (Score:5, Informative)
And why AMD and ARM may not be vulnerable to Meltdown:
Google says no such thing (Score:3)
Any word on how PCID helps mitigate? (Score:2)
Reading through a variety of descriptions I understand the attack for Meltdown, but I'm seeing less of a discussion around how patches may work - in particular I read if your model of Intel processor supports PCID (Process-Context Identifiers) a fix may not impact performance as much, but I've not seen any description of why and would be interested to know how that helps.
How does Javascript make illegal mem references? (Score:3)
One of the things I've seen flying around, is some people are saying this can be exploited in a web browser, thanks to Javascript JIT-compiling to machine code.
I am pretty damn out of date on Javascript compilers, so I was hoping someone could explain how this is possible. Javascript doesn't have pointers. I'd think that if a Javascript programmer is capable of writing Javascript code that compiles in such a way that the programmer can create a pointer of their own making (perhaps pointing to kernel memory) and can cause code to dereference that pointer, we would all call that a severe and inexcusible compiler bug.
I mean, even if there were no processor flaw at all, but the Javascript-compiled-to-x86 code could read arbitrary memory in its own browser process, that alone would be a severe web-user-killing nightmare. How is that not a compiler bug?
Am I mistaken that a Javascript exploit is possible?
Re: (Score:3)
Looks like "drive by attacks" ARE possible (Score:3)
(BTW, thanks to the people who suggested I read the Spectre paper [spectreattack.com].)
One of the things that makes Spectre so interesting, is that we're wrong!
Long story short, is that though Javascript doesn't have pointers, it can have an array of bytes. And the compilers are amazing and apparently do a really great job of turning the Javascript into machine language.
So the Javascript basically asks for
So who do I short? (Score:2)
Meltdown and spectre are not the same things (Score:2)
There seems to be a concerted PR effort to shine spotlight on everything rather than just Intel where it belongs.
Meltdown is basically heartbleed. This is NOT a side-channel attack. It allows an attacker to trick the processor to flat out be handed the value of memory address the attacker should never be able to access. The only linkage between it and spectre is incidental exploitation of speculative execution.
Spectre is exclusively a "side-channel" attack. To continue TLS analogy it's like using an AE
Re: (Score:3)
No, KPTI doesn’t help for Spectre.
Re: (Score:2)
Also Spectre and Meltdown are not the same thing.
Re: (Score:2)
Intel use weasel language to heavily imply they were in their press release. And based on comment chains on this story, it seems to have worked.
Re: (Score:2)
Crypto-coin paper wallet. Problem solved.
Re: (Score:2)