>We now know that basic operations like strlen, memcpy and strcmp will use the vector registers - so we can effectively spy on those operations happening anywhere on the system! It doesn’t matter if they’re happening in other virtual machines, sandboxes, containers, processes, whatever!
>This works because the register file is shared by everything on the same physical core. In fact, two hyperthreads even share the same physical register file.
>It turns out that mispredicting on purpose is difficult to optimize! It took a bit of work, but I found a variant that can leak about 30 kb per core, per second.
>This is fast enough to monitor encryption keys and passwords as users login!
It allows the attacker to eavesdrop on the data going through operations like strcmp(), memcpy(), and strlen(). (These are the standard functions in C for working with strings; and many higher-level languages use them under the hood.) It works on any function that uses the XMM/YMM/ZMM registers.
It's stochastic; the attacker randomly gets data from whatever happens to be using the XMM/YMM/ZMM registers at the time. So if the attacker could eavesdrop in the background constantly, they might eventually see a password. Or they might be able to trigger some system code that processes your password, then eavesdrop for the next few milliseconds.
The attacker needs to run code on your machine. Unclear if running code in a web browser is sufficient or not. It requires an unusual sequence of machine instructions, which isn't necessarily possible in JS/WASM, but 'sounds' says they did it: https://news.ycombinator.com/item?id=36849767
> If you remove the first word from the string "hello world", what should
> the result be? This is the story of how we discovered that the answer
> could be your root password!
I assume they meant "what does this do in normal vulnerability discussion terms", I don't know why tavis didn't just say "arbitrary memory read across processes" or whatever.
Beyond what everyone else said, these types of exploits can break out of VMs. Unless I'm misreading it you could log into your $5 linode/digitalocean/aws machine and start reading other people's data on the host machine.
There's tons of million dollar/month businesses on ~$20/month accounts on shared machines.
Some people think you need "the ability to execute arbitrary code in an unprivileged context" to perform this exploit. Which is of course a false assumption. The bug class in this case is basically a user-after-free, for a function which keeps its state per-cpu-core, for a function that is (for almost all intents and purposes) unprivileged.
From the article:
We now know that basic operations like strlen, memcpy and strcmp will use the vector registers -
so we can effectively spy on those operations happening anywhere on the system! It doesn’t matter
if they’re happening in other virtual machines, sandboxes, containers, processes, whatever!
All you need to do is write some JavaScript that will "trigger something called the XMM Register Merge Optimization2, followed by a register rename and a mispredicted vzeroupper". It's up to the hacker to determine how to do this explicitly in JS, but it's theoretically possible by literally any application at any time on any operating system. Even if some language or interpreter claims to prevent it, it's possible to find an exploit in that particular language/interpreter/etc to get it to happen.
This is how exploit development works; if you can't go straight ahead, go sideways. I guarantee you that someone will find a way, if they haven't yet.
I would like to think that the likelihood of being able to find a juicy target using one of these specific CPUs and who would have explicitly not updated their microcode for this exploit is much much much higher going after end users on the web than by attacking organized VPS providers.
> The attack can even be carried out remotely through JavaScript on a website, meaning that the attacker need not have physical access to the computer or server.
> Currently the attack can only be executed by an attacker with an ability to execute native code on the affected machine. While there might be a possibility to execute this attack via the browser on the remote machine it hasn’t been yet demonstrated.
We are on a tech site with highly intelligent individuals who have been programming computers since we've been in diapers.
If you don't believe the text then how would you believe the video? Anything can be done in devtools beforehand and I can think of a million different ways to fake the video.
Personally, if I didn't trust the text then an easily faked video wouldn't placate me either.
No, only the ability to execute arbitrary code in an unprivileged context. Would probably have to be arbitrary x86_64 instructions - Javascript wouldn't cut it for this one.
Also, he's using an AMD graphics card. AMD GPUs are infamous for stuttering issues and framerate problems on Windows.
I tried a RX580 pre-pandemic and it was both a space heater with massive power consumption, framerates were wildly inconsistent in several games, and I had game crashes.
The author suggests that comparing Arm vs. x86 is easy due to a Geekbench test comparison. That's one of very few cross-platform benchmarks and highlights the fact that the author isn't very well-versed (if versed at all) in competitive performance analysis or PC benchmarks.
Geekbench is a terrible proxy for ANY workload, those subtests all run within the space of a few seconds -- they aren't meant to actually represent performance in sustained workloads.
Additionally, the smashing together of results from a wide range of incomparable applications, including unfair weighting that skews for memory, makes the cumulative scores largely worthless.
Finding other relevant benchmarks for comparison is difficult, especially given the locked down nature of MacOS.
As we know, processors run a series of instructions, things like "move data," "add," "store data."
Over time, these instructions have gotten more and more complicated. Now there are "instructions" like "Enter Virtual Machine Monitor" which actually complex manipulations of tons of different registers, memory translations, and subsystems inside of the CPU.
And, even simple, primitive instructions like call, jump, and return actually need to check the state of various pieces of the processor and edit lots of internal registers, especially when we start to consider branch prediction and issues like Spectre.
It wouldn't be very plausible to hard-wire all of these complex behaviors into the CPU's silicon, so instead, most instructions are implemented as meta-instructions, using "microcode." "Microcode" is just software that runs on the CPU itself and interprets instructions, breaking them down into simpler components or adding additional behaviors. Most CPUs are really emulators - microcode interprets a higher level set of instructions into a lower level set of instructions.
Historically, Intel and more recently AMD have encrypted this "microcode," treating it as a trade secret. This makes people who are worried about secret hidden backdoors _very_ worried, because their CPU's behavior is depending on running code which they can't analyze or understand. This has led to all sorts of mostly unfounded speculation about secret back doors, CPUs changing the behavior of critical encryption algorithms, and so on and so forth.
Decrypting this microcode will theoretically allow very skilled engineers to audit this functionality, understand the implementation of low-level CPU behaviors, and find bugs and back-doors in the CPU's interpretation of its own instructions.
Replacing this microcode silently would be absolutely catastrophic security-wise, because an attacker could silently change the way the CPU worked, right out from under running software. But, there is no evidence this is possible, as the microcode is digitally signed and the digital signature implementation, so far, seems to be correct.
One guy in China (with dual US citizenship) went rogue and refused to step down as CEO of a joint venture after board members representing most of the shareholders (including Chinese shareholders) voted to remove him.
He could only do that based on a legal technicality and the shareholders can still oust him via court action.
It makes absolutely zero sense for Crucial to implement such a warranty restriction - This is already covered under the endurance portion of the warranty. Making a clause that ANY use of the SSD for mining automatically voids the warranty is like saying your car warranty is void if you use your car to get groceries.
Crucial quoted its own warranty falsely and then attempted to implement that change retroactively. That's certainly grounds for a class-action lawsuit. They were smart to back down from this.
Except he didn't re-hire him. As noted in the article itself, the architect was already in negotiations since November. Also, new CEO doesn't step in until next month. Clickbait title.
The effect of Gelsinger taking the CEO role pushed a hire that was on the fence into accepting the role. It means he's having an affect already. That's what the title is meant to convey.
The title does a bad job of this, though, as it's extremely ambiguous who is doing the "rehiring." The way it's worded, the best assumption is the "New Intel CEO" is doing the "rehiring" - but Pat did not do this.
> The effect of Gelsinger taking the CEO role pushed a hire that was on the fence into accepting the role.
That's what he says and it is probably true. But it could also be true that saying so would put him in good graces with the new CEO and he would basically be expected by everyone to say that's what pushed him over the edge even if it wasn't, so him saying so adds little new information.
I seriously doubt that. He could have just stayed retired.
If the negotiation was all smooth he would have been working with Intel by now. Remember he was retired, he doesn't need 30 / 60 days notice to anyone apart from family.
Intel needed help, but sometimes even money cant move some people. They fail to attract any talent, especially those who have already worked in Intel and knows their culture.
Having Pat meant finally shit will get done. And for most engineers, that is far more important because we all hate politics.
The timing of his acceptance adds information and makes me lean towards the explanation being true. The statement of the explanation adds very little information though.
IMO the headline is sensationalist and factually inaccurate. Gelsinger hasn't re-hired anyone. He doesn't even take on the new role at Intel until approximately three weeks from now.
"AMD's computing and graphics segment, responsible for both the EPYC server and console chips, generated $1.44 billion, a 21% year-over-year decline. AMD chalked this up to lower sales into the console market, while increased EPYC Rome sales reduced the impact.
In either case, the market's bullish prospects for AMD's EPYC Rome processors might be blunted by the lower revenue generation in this key segment. The unit posted a $26 million operating loss, compared to operating income of $45 million in the fourth quarter of 2019. AMD cited lower ASPs due to heightened cloud spending, and we know that Intel has been increasingly competitive as it slashed pricing on its competing Cascade Lake Refresh processors. Intel's server unit (DCG) also recently posted a 42.7% year-over-year sales increase due to coronavirus-spurred demand."
The fact that the Super 7 don't want to rely upon one vendor actually gives AMD a better shot - all other serious contenders use different instruction sets, so AMD's x86 procs are compatible with existing software ecosystems, thus reducing qualification and validation results. A viable x86 alternative to Intel has been sorely needed, and AMD fills that role quite nicely.
It certainly is in terms of power, performance, and cost, but Intel's reputation for rock-solid reliability and a decade of optimization for its architectures, not to mention the established software/support ecosystem, means AMD has a very long haul ahead of it.
Sorry, but especially on servers amd has a better track record with reliability. You are right with missing optimizations on some software stacks but that’s not a long haul it’s just that nobody saw the need to do it until now. Don’t forget all the loss of performance from spectre mitigation a lot of datacenters lost up too 25% performance overnight. Everyone is going amd. Google/Facebook/Disney/Pixar...
Turn on "showdead" in your profile, then look at their comments. Usually it's easy to tell why it's happened, but if there are comments that don't deserve to be dead, you can "vouch" for them individually to help resurrect them (click on comment timestamp, then click "vouch"). That has happened here.
