“The newly developed Rowhammer- attack TRRespass can crack the RAM-a security mechanism by many DDR4-DRAM-modules as well as LPDDR4 Chips. Until now, these were considered to be almost immune to Rowhammer attacks.”
Zombieload is back.
“This time a new variant (v2) of the data-leaking side-channel vulnerability also affects the most recent Intel CPUs, including the latest Cascade Lake, which are otherwise resistant against attacks like Meltdown, Foreshadow and other MDS variants (RIDL and Fallout).” (src: thehackernews.com)
Update: 2019.05 Microsoft, Apple, Google Release Updates to Address Microarchitectural Data Sampling (MDS) Vulnerabilities Impacting Most Chips Made by Intel
Millions of computers powered by Intel processors are affected by vulnerabilities that can be exploited by malicious actors to obtain potentially sensitive information. Intel and other tech giants have already released patches and mitigations.
The side-channel attack methods, named ZombieLoad, RIDL (Rogue In-Flight Data Load), and Fallout, are similar to the notorious Meltdown and Spectre, which researchers first disclosed in January 2018. At the time, experts accurately predicted that other similar speculative execution attacks would be discovered.
The attack methods work against both PCs and cloud environments, and they can be launched against most Intel CPUs made in the past decade. The techniques can be used to get applications, the operating system, virtual machines and trusted execution environments to leak information, including passwords, website content, disk encryption keys and browser history.
For example, experts have demonstrated that hackers can use the ZombieLoad attack, which is a subclass of RIDL, to obtain a user’s browsing history even if the victim surfs the web from a virtual machine and uses the Tor anonymity network. (src: securityweek.com)
Update: 2019.04 “Speculative Execution”
Update: 2019.02: ExSpectre: Hiding Malware in Speculative Execution
“Co-authored by three computer science boffins from the University of Colorado, Boulder in the US – Jack Wampler, Ian Martiny, and Eric Wustrow – the paper, “ExSpectre: Hiding Malware in Speculative Execution,” describes a way to compile malicious code into a seemingly innocuous payload binary, so it can be executed through speculative execution without detection.” (src: theregister.co.uk)
Update: 2019.01: Redhat CPU fixes overview: Is CPU microcode available to address CVE-2017-5715 via the microcode_ctl package?
Update: 2018.12: ForeShadow – guest reading Level1 Cache of host
ForeShadow (known as L1 Terminal Fault (L1TF) by Intel) is a vulnerability that affects modern microprocessors that was first discovered by two independent teams of researchers in January 2018, but was first disclosed to the public on 14 August 2018. The vulnerability is a speculative execution attack on Intel processors that may result in the disclosure of sensitive information stored in personal computers and third-party clouds.
Update: 2018.07 – it’s getting worse – steal bytes WITHOUT RUNNING ANY CODE
this attack is SUPER SLOW but it could steal arbitrary Bytes (how many bytes are one root password? (well yes you would to have to know in advance where exactly the root password is in memory and then it is probably (hopefully) not in an unencrypted state but in an sha512sum hashed/encrypted state) from routers and servers WITHOUT RUNNING ANY CODE on the system itself?
(this will hit the AngularJS, JQuery and NoScript guys BADLY, Richard Stallmann is right.)
… intel, i think you just broke the internet.
Update: Android and ARM affected – iPhones too?
“Over the last two years, the Rowhammer bug transformed from a hard-to-exploit DRAM disturbance error into a fully weaponized attack vector”
Paper on RowHammer: https://gruss.cc/files/rowhammerjs.pdf
Doesn’t this sound great?
2015: RowHammer.js (src)
“Insanity: doing the same thing over and over again and expecting different results.”
Albert Einstein – Who did not live long enough to see Rowhammer
Google is downplaying the problem.
the paper continues:
“Researchers demonstrated exploits not only against desktop computers, but also used single bit flips to compromise the cloud and mobile devices, all without relying on any software vulnerability.
Since hardware-level mitigations cannot be backported, a search for software defenses is pressing.
Proposals made by both academia and industry, however, are either impractical to deploy, or insufficient in stopping
Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation
risc v is very new: https://wiki.debian.org/InstallingDebianOn/SiFive/HiFiveUnleashed
why no ethernet port per default? Freedom U540
From: David Woodhouse Date: Sun Jan 21 2018 - 15:28:51 EST
- Next message: ulrik . debie-os: “Re: [PATCH] Input: trackpoint – force 3 buttons if 0 button is reported”
- Previous message: David Lechner: “[PATCH] mmc: davinci: suppress error message on EPROBE_DEFER”
- In reply to: Andy Lutomirski: “Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation”
- Next in thread: Linus Torvalds: “Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation”
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sun, 2018-01-21 at 11:34 -0800, Linus Torvalds wrote: > All of this is pure garbage. > > Is Intel really planning on making this shit architectural? Has > anybody talked to them and told them they are f*cking insane? > > Please, any Intel engineers here - talk to your managers.Â If the alternative was a two-decade product recall and giving everyone free CPUs, I'm not sure it was entirely insane. Certainly it's a nasty hack, but hey â the world was on fire and in the end we didn't have to just turn the datacentres off and go back to goat farming, so it's not all bad.
my comment: that is exactly what Intel OUGHT to do: recall all CPUs of the last 20 years.
IMHO the “motive” of intel/AMD is pretty clear: “yes we admit our product is flawed – we try to give you a choice: flip the IBRS_ALL bit and get a 20% speed penalty but (probably) fix the security whole. Or leave the whole wide open because your infrastructure is physically shielded against intruders and NOT connected to the internet.”
Another possibility: fire their managers close down and start over under a new name with a new design and a hacking team that tries to constantly break things?
That would be the clean thing to do to save their economic asses uh i mean assets.
But that will not be enough: Intel / AMD / CPU and Hardware manufacturer: To avoid future mistakes follow the UNIX philosophy: 1. Simplify 2. Simplify 3. Simplify – everything.
if you don’t believe me, you might believe: McIlroy:
“We used to sit around in the Unix Room saying, ‚What can we throw out? Why is there this option?‘
It’s often because there is some deficiency in the basic design — you didn’t really hit the right design point.
Instead of adding an option, think about what was forcing you to add that option.”
Never the less errors will be made: If architectural / design errors surface that can not be fixed by software – there should be some kind of recall mechanism, but this is expensive for the producer, so what probably happens is: Make the customer / re-seller bear the risk: If you want to run a Intel based computer, you will have to agree to some disclaimer like on software:
“THIS CPU IS SOLD “AS IS” WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
You are solely responsible for determining the appropriateness of using or redistributing this CPU and assume any risks associated with Your exercise of permissions under this License.”
Means: We don’t know if we just sold you a bunch of crap technology with unfixable security wholes – because this product is so complex – we kind of lost control over it’s quality – so all risk is on YOU!
That is just how mankind is: Apes with complex technology and technology dependent lifestyles that could get out of hand if no learning curve existed: so simplify, simplify, simplify!
Let’s just hope your lifestyle has no unfixable security problems.
Even worse: The monetary system actually might “encourage” to repeat mistakes such as war – because it is good money for the “hardware” (weapons) manufacturers.
And that is exactly what Intel will do: Save it’s ass – despite the flood (32 and more) lawsuits.
So Intel tries to sell it’s fix as “security” and will not compensate the damaged datacenter owners – which probably are forced to rebuy, rebuy, rebuy Intel’s new CPU or go to an alternative CPU manufacturer that does not have this trouble (is there still one? Apple gave up on that… MISTAKE! another reason why monoculture sucks – not only in farming and nature).
Look at traffic: You could go by train, by car or by bus or by airplane or bicycle or horse or elephant or soon: DroneTaxi or Elon’s HyperLoop or simply: walk.
There are basically completely different “methods” of doing the same thing: travel distances and/or transport stuff.
And thus provide redundancy for the: travel/transport problem.
But redundancy costs money… repeating mistakes does too.
This could be THE CHANCE for alternative CPU manufactureres and maybe even: Open Hardware?
“The RISC-V Foundation says that no currently announced RISC-V CPU is vulnerable to Meltdown and Spectre”
“Until recently, RISC-V hadn’t seen much adoption in industry, but, in the past two years, Nvidia and Western Digital both announced that they would be adopting RISC-V CPUs. In light of the recent Meltdown/Spectre issue, the RISC-V foundation has released a statement on the vulnerabilities’ impact on RISC-V development.”
“As CISC raises too many verification problems, and a closed-source chip design cannot be trusted, the only solution is open-source RISC:”
OpenSPARC T1 is the open source version of the UltraSPARC T1 processor, a multi-core, 64-bit multiprocessor. The UltraSPARC T1 processor with CoolThreads technology was the highest-throughput and most eco-responsible processor ever created when it became available in the UltraSPARC T1 system. It was a breakthrough discovery for reducing data center energy consumption, while dramatically increasing throughput. Its 32 simultaneous processing threads, drawing about as much power as a light bulb, gave customers the best performance per watt of any processor available.
OpenSPARC T1 source components are covered under multiple open source licenses. The majority of OpenSPARC T1 source code is released under the GNU General Public License. GNU General Public License Source based on existing open source projects will continue to be available under their current licenses. Binary programs are released under a binary Software License Agreement.
Is Open Source RISC-V Ready to Take on Intel, AMD, and ARM in the Data Center?
LinuxGizmos.com:”Aside from being open source and customizable, one of the main benefits of RISC-V is that it is fully modern, purpose built, and unburdened with legacy code.”
… but only if we (can) buy it.
Debian supported CPU architectures:
Motorola 680x0: | m68k - Atari | - atari - Amiga | - amiga - 68k Macintosh | - mac - VME | - bvme6000 | - mvme147 | - mvme16x | DEC Alpha | alpha | - generic | - jensen | - nautilus | Sun SPARC | sparc | - sun4cdm | - sun4u The UltraSPARC class systems fall under the sun4u identifier, and are supported using the sun4u set of install images. | ARM and StrongARM | arm | - netwinder | - riscpc | - shark | - lart | IBM/Motorola PowerPC | powerpc - CHRP | - chrp - PowerMac | - powermac, new-powermac - PReP | - prep - APUS | - apus | HP PA-RISC | hppa - PA-RISC 1.1 | - 32 - PA-RISC 2.0 | - 64 | Intel ia64-based | ia64 | MIPS (big endian) | mips - SGI Indy/I2 | - r4k-ip22 | MIPS (little endian) | mipsel - DEC Decstation | - r4k-kn04 | - r3k-kn02 | IBM S/390 | s390 | - tape | - vmrdr
… the mail continues:
As a hack for existing CPUs, it's just about tolerable â as long as it can die entirely by the next generation. So the part is I think is odd is the IBRS_ALL feature, where a future CPU will advertise "I am able to be not broken" and then you have to set the IBRS bit once at boot time to *ask* it not to be broken. That part is weird, because it ought to have been treated like the RDCL_NO bit â just "you don't have to worry any more, it got better". https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-Side-Channel-Mitigations.pdf
We do need the IBPB feature to complete the protection that retpoline gives us â it's that or rebuild all of userspace with retpoline. We'll also want to expose IBRS to VM guests, since Windows uses it. I think we could probably live without the IBRS frobbing in our own syscall/interrupt paths, as long as we're prepared to live with the very hypothetical holes that still exist on Skylake. Because I like IBRS more... no, let me rephrase... I hate IBRS less than I hate the 'deepstack' and other stuff that was being proposed to make Skylake almost safe with retpoline.
“As a programmer, it is your job to put yourself out of business. What you do today can be automated tomorrow.”
Damn this guy is a philosopher.