New trade deal
So basically we are going to end up having to buy shitloads of Intel processors and Boeing aeroplanes?
Intel on Monday issued a processor data leakage advisory, describing two chip architecture flaws, one of which it tried to fix twice before. The memo, INTEL-SA-00329, covers two security vulnerabilities: CVE-2020-0548, dubbed Vector Register Sampling, and rated 2.8 low severity, and CVE-2020-0549, described as L1D Eviction …
...we really have to stop with all this branding lark. This is a CVSS 6.5. For most organisations that ranks somewhere between "huh, interesting" and "hrm, maybe we'll get to it at some point" on the Practical Security Threat Index. It does not warrant a press release, a new domain, a bombastic FAQ and much self-congratulatory passing around of credit and pats on the back for being ever-so-responsible [but not responsible enough to wait for patches to be actually released...]. We're training audiences to only care about vulnerabilities if they've got a natty little logo and a DNS-friendly name. It's just getting silly now.
the 2.8 is a maybe patch sometime next century being below the PDSS 4.3 threshold
the 6.5 might be worth a look posibly next patch cycle
the issue is if someone chains this with some other nasties to make it remoteley exploitable, if your risk profile is where you need to worry about Sheiks sending whatsApp messages, you probably need to look at both, but otherwise, the 6.5 would do.
@ " [but not responsible enough to wait for patches to be actually released...]"
IMHO Intel designers were aware of the implications of reducing security for performance gains years ago, how much longer should the consumer have to wait before a light is shone on their bad decisions.
I can understand you being upset that your investment in intel was based upon false information but resenting the truth and those that give it is a bit childish when you should be mad about intel conning you in the first place.
I still have a stick of Z80's in the cupboard and a few 8080's, I'm sure that, given the flaws in modern processors that are being unveiled every month, these chips have a lot more value now.
Cache problems appear all the time these days, maybe we need to develop a processor that puts security above features. But seriously, does anyone actually consider security when they design and sell anything these days?
Version 1.0,
"But seriously, does anyone actually consider security when they design and sell anything these days?"
Apparently not, and not for a long time it appears !!!
Intel must have been asleep at the wheel or more likely thought that it was an acceptable risk ... much like Boeing.
Could this be a American business problem where 'Profit' trumps (no pun intended ... really!!!) all else.
But those are so slow. I think some 2002 P4s are faster?
Also some 64 bit Atoms deliberately have too few address bits. Is the limit 2G byte external addressing on some?
I've a 10" Win10 Atom tablet, made for Win 10 and a 2002 P4 laptop is faster as is a 10" ARM tablet (much much faster). A least a Z80 didn't usually get loaded with software it couldn't sensibly run, unlike Win10 on some Atoms.
There is an OS* for the Z80 that uses its 'spare' register set to make a multitasking OS that can use 1 meg of ram so potentially you could try and run something that would take rather longer than usable. Having said that there is 100GHz cmos (Intel doh) which could be used to knock up a z80 and its ram and do something interesting!
*https://en.wikipedia.org/wiki/SymbOS
Various sources claim all Atoms are vulnerable to Zombieload and perhaps to RIDL and other MDS attacks as well. The original Bonnell microarchitecture for Atom has Hyperthreading, which suggests it would be vulnerable to type-1 Zombieload.
I admit that I pay little attention to Intel's twisty maze of CPU families, however, and much of the discussion of the MDS vulnerabilities isn't directly supported by anything I've seen in one of the actual research papers.
Security isn't sexy, MIPS are sexy... That is the problem, each new processor needs to be faster, not safer, than its predecessor.
In the old single-user not internet connected days, that wasn't a real problem. Today it is coming back to bite us.
That said, most of the exploits so far are theoretical with very few having been turned into actual malware - most of them require direct access to the machine, in which case the exploit is moot. Multi-tenant being the possible exception.
The original SPECTRE paper demonstrated in-browser attacks, as did the Zombieload paper.
Multi-tenant is at risk. Privilege boundaries are at risk if you have an RCE in an unprivileged process. Enclaves are at risk (though, seriously, fuck enclaves; do they have a real use case other than DRM and spyware?).
We haven't seen in-the-wild exploitation of these vulnerabilities because:
1. Disclosures have been embargoed until the most prominent targets could be remediated. That's what happened with the browser-based exploits for SPECTREv1.
2. We have no shortage of easier-to-use exploits for untargetted attacks, and frequently for targetted attacks as well.
3. Microarchitecutural exfiltration attacks are hard to detect, so they may well have been used in targetted attacks without anyone being the wiser. Just like we have no idea how many victims there were for Heartbleed.
That was my point. There are demonstrable attacks out there, but they are so slow, complicated, error prone and hard to implement that there are other, easier methods for most attackers.
And, apart from multi-tenant, you already have to be in a position to execute the code on the device, so there are easier methods of getting the information.
Every recent Intel review was just invalidated because the new microcode will certainly hurt performance, yet again. One can no longer trust comparisons made between new chips and those tested previously unless the reviewer re-tests each example with the current microcode and OS patch sets. Of course the same applies to the weekly release of new game-optimized video drivers. Welcome to "interesting times."
"unless the reviewer re-tests each example with the current microcode and OS patch sets"
Except the current microcode and OS patch sets don't fully fix the issues. Given how long ago the SPECTRE and MELTDOWN vulnerabilities were revealed and Intel's hitherto apparent inability to mitigate along with the fab cock-ups, I'm beginning to wonder if there's anyone with 2 brain cells to rub together left at Intel?
With current generation Cascade Lake Xeon's, they are largely resistant to CacheFlow already due to design changes with cache synchronisation.
Given that no processor that uses a SMT design can mitigate SPECTRE issues without OS/software changes and MELTDOWN has already been mitigated in Cascade Lake, I'm unsure where your expectation of a "full fix" comes from.
If you want a "full fix", disable hyperthreading/SMT but then I suspect you will complain about a loss of performance...
The fab cock-ups are a separate issue - Intel tried something that didn't work with the technology at the time. If they fix their 10nm issues in 2020/2021 with new ASML equipment (that TSMC is already using), we may even look at these issues in a different light.
I spent a decade doing microprocessor validation at AMD & IBM, 1996-2006.
Of course, security is a multi-layered beauty, but there are entire classes of hardware issues that no amount of software can mitigate. (Unless the software disables the relevant hardware feature--which is not always possible.)
Meltdown is an entirely different class of fail from Spectre, which is why Meltdown is Intel specific. Very annoying that they've not been willing to fix it. (And I use this language deliberately. The techies have had plenty of time to figure out what options will properly close this off. It's the VPs not wanting to take the hit that are the problem.)
Spectre-class leaks cannot be software mitigated without turning off speculative execution in current hardware. Full stop. You could design an architecture that had a speculative cache buffer (for EVERY level and type of cache). It would be complicated, but it would deal with Spectre-class issues.
Timing attacks on the execution buffers is a different thing. If the attacker controls all but one of the hardware threads, it is game over. So, two-threaded processors are particularly vulnerable on that account. With four threads, the OS could prevent any process from having multiple threads on a core to protect sensitive computations, or only permit threads from one process per core.
Cache-flush timing attacks are really ugly, as the entire point of a cache is to speed execution. There might be something that could be done with orphan buffers, but in the worst case, the OS would have to only permit threads from a single process to execute at once, and to flush the caches between process switches.
Plenty of smart folks at Intel.
Sadly it would seem none of them are in a position whereby they are able to say "maybe we should do the more expensive thing our engineers have been suggesting, maybe it is worth losing some margin".
As at most places, there will be talent, and that talent will be reminded to stay in it's bloody box and do as it's told. Stop being so negative. Etc.
Any type of external memory is far slower than the level 1 cache memory. There are a number of unavoidable delays in accessing external memory (the speed of light being one of them). SRAM with the same cycle rate as the level 1 cache memory has a high power requirement. CPUs have only small amounts of L1 cache so the power consumption is acceptable - having gigabytes of memory with that speed would result in PCs acting as high power heaters (multiple KW).
@"Any type of external memory is far slower than the level 1 cache memory."
Anything accessed across the main bus is going to be slower than direct access and current design is still based upon the idea of centralizing the expensive logic into as few packages as possible and connecting everything else via a bus.
This is not the only way of building a computer
"FFS just start making SRAM DIMMs already."
Are you implying that SRAM will fix the Cacheflow flaw?
a) on-chip cache is already SRAM for speed so putting it further away will slow it down significantly as latency becomes your main issue
b) as SRAM is already used for cache, the security issue wouldn't be addressed. Changing the CPU to not use cache-type structures to reduce latency will slow the CPU's down even more as they are left sitting waiting for responses from main memory for any memory operations.
c) massively increase RAM power/cost as SRAM requires 4-6 transistors per bit versus 1 per bit for DRAM.
Mine is the one with the FPGA in the pocket... I wonder what an i7 equivalent would size at, and if you could even GET the performance out of the complex structure needed to emulate one in hardware.
But it'd be a wonderful toy to play with. :D
PS, "Field-programmable gate array" not flipped pin grid array... I guess someone in marketing was trying to fake a cannibalism of a different market by using the same acronym.
As with Meltdown and Spectre, we've yet to see any meaningful malicious exploitation of these holes in the wild, though that doesn't mean they can be ignored.
You might like to think malicious exploitations are not to be featured/servered with applications out in the wild ........ that place/space where renegade rogue pirates privately rule for ....... well, Absolute Dominion in a Virtual Domain presents one with Almighty Impeccable Tools to Prove Worthy of Heavenly Use rather than entertaining its mischievous malinformed twin, Ignorant Wanton Abuse ...... which is surely classified at least as an UnSavoury Madness.
Would you fear the complete opposite, ... positive reinforcing, mutually beneficial, remote virtual executive exploitation of systems infected/infiltrated?
Or welcome it, with calls for demonstrations to confirm veracity with avowed intent?
Who/What do you imagine today would have a vital leading interest in such an Almighty Impeccably Tooled Future? Take a wild guess, for in there will most probably be practically all of the answers :-)
It's all very "Help, the sky is falling."
None of these cache issues are likely to be exploitable in the real World. Gaining access to the data in some random block of memory that you should not have access to is one thing. Gaining access to memory that you have targetted and not only know what wrote to it last and what the data represents, but that also contains information that would be useful to the malicious actor (such as an encryption key or password) is another thing entirely. The machine that the malicious code is running on will almost certainly be running an unknown mix of programs each using unknown segments of memory. It would be like putting together a page from a moving conveyor belt of document shreddings by pulling out strands at random. Theoretically possible, but not sufficiently likely to be worried about.
Certainly, in isolation, these issues border on NBD. OTOH, Intel has a long history (FP divide?) that stretches to the present of not fixing anything until it was unable to bear the media heat. Given that one of these issues is "Hey, that thing you said you fixed six months ago? You lied.", I believe that making a circus of things is pretty well demonstrated to be the ONLY way to get Intel to seriously address issues.
Intel created this environment. The rest of the industry is responding to it.