Meltdown The Sequel strikes Intel chips – and full mitigation against data-meddling LVI flaw will slash performance

Computer security researchers involved in the discovery of the Meltdown and Spectre vulnerabilities affecting many modern processors have developed a related attack technique called Load Value Injection (LVI). The attack relies on microarchitectural data leakage to inject and execute malicious code in a way that breaks the …

[Cave-Homme]

Well, the average bod has got no effing chance to protect themselves.

Until the authorities get serious with cyber criminals and either castrate them, or lock em up on Rockall and throw away the key, or ideally both, then we've got no chance of stopping this.

[LeoP]

The average bod vs. the average conman

Of course we see from the enlightened example of our Trumpian friends, that draconian punishment (including death) are a near guarantee for a very low-crime environment, peacfull streets and no cybercrime at all.

Speaking of it: Are you interested in an investment opportunity into an essential and lucrative bridge?

[Anonymous Coward]

Re: The average bod vs. the average conman

> Are you interested in an investment opportunity into an essential and lucrative bridge?

I sold that bridge already. Three times.

[seven of five]

Re: The average bod vs. the average conman

Yeah. twice to the OP, I´d guess...

[Anonymous Coward]

If these exploits carry one

Apple will jump ship to their own ARM based processors even sooner.

Other makers may well desert Intel and switch to AMD.

I would not be looking for much in the way of caree progression if I worked at Intel. They really do look rather beleagured these days.

[JohnFen]

Re: If these exploits carry one

> Other makers may well desert Intel and switch to AMD.

And personally, I'd already determined to avoid Intel CPUs entirely a couple of years ago.

[Anonymous Coward]

Re: If these exploits carry one

In the meantime, I just bought a pair of intel Xeon E5-2697v2 for 340GBP to upgrade the legacy system I own. They used to cost 2000 each.

[whitepines]

Re: If these exploits carry one

Other makers may well desert Intel and switch to AMD.

Out of the frying pan and into the fire. There's an article today in this august publication exposing an AMD speculative vulnerability, and AMD has yet to be scrutinized as heavily as Intel.

Two sides of the same coin, really. More concerned with protecting Hollywood interests and commercial software than with the security of your data.

[Anonymous Coward]

Re: If these exploits carry one

Researchers in the new AMD paper literally used previous Spectre vulnerabilities and outdated libraries to attack the system. All these have been patched before the research was even started. They only used some new AMD cache layout information to speed up the already patched vulnerabilities. If the researchers had used up to date operating system and libraries the attacks in the paper would not have been possible.

And all this was generously funded by Intel and was scheduled to be disclosed just between the Intel unfixable chipset vulnerability which jeopardizes Intel's Trusted Platform Module & DRM implementations of last week and this new Intel performance killing reverse Meltdown vulnerability.

The only people to think this is the same side of the coin are people who have no secure software development background and only count the occurrences of "Intel" and "AMD" in news titles.

[Anonymous Coward]

Re: If these exploits carry one

From the FA: "We believe that none of the ingredients for LVI are exclusive to Intel processors," ...

"tl;dr;must comment" ?

[LeoP]

Re: If these exploits carry one

Also from the FA: "However, LVI turns out to be most practically exploitable on Intel processors because of the combination of the facts that we have seen more Meltdown-type leakage sources there that can potentially be inverted, plus certain design decisions that are specific to the Intel SGX architecture (i.e. untrusted page tables)."

Quote-picking doesn't alter the real world.

[MacroRodent]

Re: If these exploits carry one

The common thread in all these exploits is speculative execution, which is performed by all advanced CPU:s these days.

I wonder if this sparks interest in research on architectures that would be reasonably efficient without speculative execution.

What was the last Intel CPU without speculation? The original Pentium, I guess.

[Claptrap314]

Re: If these exploits carry one

I spend a decade in microprocessor validation, 1996-2008 at AMD & IBM.

The short answer: no. SpecX is a huge performance gain. This has to do with things like the speed of light, and the size of gates on-chip verses the minimum spacing between wires off-chip. We simply cannot get data in and out of the chip fast enough to keep up, so specX allows us to do a LOT of work while we wait.

It does not surprise me at all at the 2-20x cost of serializing every load. I'm pretty sure the number is that low only because of the existing attempts to evade Spectre- & Meltdown-class problems have taken so much performance.

[Anonymous Coward]

Re: If these exploits carry one

@"The short answer: no" true whilst computers continue using the same design that John von Neumann pointed out came with bottlenecks before computers became commonplace.

There have been many other designs that decentralise the processing but at a cost of require greater hardware and interconnect redundancy that for years were rejected as being too expensive however now the cost of production has become much less of a factor and the need for change greater, IMHO we don't really have a choice anymore.

For computing to continue there has to be a move away from what we now know doesn't work for us, the sooner this is accepted the sooner the field can move forward.

@"We simply cannot get data in and out of the chip fast enough to keep up" then do not move the input data only the results and accept that not all of the logic will be in use at once. Good for heat dissipation as well as allowing for shorter output routes since you can move the processing logic to where it is needed. Yes it comes with significant changes to changes to how the machine is programmed but a move from the current programming method is log over due.

[unimaginative]

Re: If these exploits carry one

Maybe you can answer a question I have had for a while.

How would dropping things like speculative execution and having more smaller cores compare - assuming parallelisable workloads would having more cores at a similar cost make up for them being slower?

[Peter Gathercole]

Re: If these exploits carry one

I can see that you're not that familiar with process and thread dispatch on current multi-core processors.

There are many long answers, but I'll try to give you a couple of short ones.

1. Lots of small processors are good executing lots of small threads/processes. They're bad at executing small numbers of large processes.

2. Accessing memory becomes exponentially more of a bottleneck as the processor count increases unless you implement a NUMA model.

3. If you choose a NUMA model, maintaining consistent performance becomes more difficult as memory closeness to the core executing the code becomes relevant.

4. The more processors you have, the more difficult it becomes to keep your memory caches consistent, which in itself can allow sideband memory attacks.

5. If using a monolithic kernel, locking contention on kernel memory structures by processes running on different processors can cause performance issues.

The large multi-core systems that can be bought now try to eliminate some of these problems by using static processor allocation to VMs, allowing the system to allocate memory for VMs based on affinity to the cores in a NUMA implementation, and to reduce the number of processors contending for kernel locks.

I'm sure there are lots of other reasons, but these came off the top of my head.

[unimaginative]

Re: If these exploits carry one

Thanks for the answesr.

Its really 1. that I was asking about, which I think you are implying would work well.

4. is something I had not realised and could be a real problem. How would the risk of attacks compare?

[Claptrap314]

Re: If these exploits carry one

If you are simulating hurricanes or nuclear bombs, if you are raytracing a scene, or trying to fold proteins or a hash collisions, sure. If you are running a desktop NOT doing the above, or things like that, not at all so much.

It turns out that most code is shockingly "near-linear". We have very few places where having 100 cores makes any sense at all.

Numa systems can be viewed as having no main memory, just an L4 cache on each processor. And cache timing attacks are inherent in having a cache.

[big_D]

Re: If these exploits carry one

AMD have their own problems with the exploit released this week.

[conscience]

Re: If these exploits carry one

@big_D & the 'what about' types:

No, AMD do not have their own problems - other than Intel predictably funding 'research' as part of a defamation PR exercise to try to limit the damage done by the public hearing about yet more extremely serious flaws in Intel's entire range of processors. Intel always resort to this behaviour, it is exactly what they did the last time they were exposed for serious flaws being discovered in their processors. But if you look into it, you'll find all the accusations aimed at AMD and other rivals are as unfounded as usual, and all these data-leaking defects are specifically Intel processor problems, not processor industry problems.

How typical it is of Intel to try to drag everyone down with them so that they don't look quite so bad in comparison to their rivals, rather than directing their attention to actually fixing their processor designs. The truth is that Intel's chips are totally broken; they are insecure, much slower than advertised and they are getting slower all the time due to all the defects that are leaking private data everywhere like a leaky bucket. AMD's only 'problem' will be manufacturing all the extra chips they will need to steal some more of Intel's market share.

All this underhand propaganda really shows is the enormity of Intel's desperation and it highlights that Intel are trying to hide the fact that their own chips are slow and insecure garbage compared to those from AMD. Intel would absolutely love everyone to think this affects all processors so it won't affect their sales, but other than non-techie consumers, us techies and those who know about these things will never believe it.

[whitepines]

Re: If these exploits carry one

I suspect I have found one of those irritating serial downvoters on any comment that dares even so much as hint AMD isn't some sort of panacea.

What's your answer to the AMD PSP? Just trust AMD do to do the right thing with their firmware, especially since they have no penalties if they do leak data from that firmware?

It's entirely within the realm of possibilities for one team in AMD to make a good core and another team inside AMD to hobble it with DRM interest related rubbish. I believe the technical term is "shooting one's foot".

[conscience]

Re: If these exploits carry one

Not at all whitepines, please don't confuse me for a fanboy. You seem to assume I am a serial down voter just because I think Intel are up to their old tricks again? Don't you think they are? Or is it just coincidence Intel has once again funded 'research' that attempts to put their rivals names in negative security related headlines and make their current cock up every manufacturers problem, while getting themselves off the hook as the sole processor maker in trouble in the court of public opinion, and all right after they get eviscerated by the media for yet more severe flaws in their chips? Again. Call me a cynic, but I am suspicious of Intel's timing and motives, therefore I suspect the validity of their claims. I am sure if and when bugs in AMD's designs are revealed, they will come to light with proper, independent, trustworthy research, just like the Intel flaws did, rather than with the help of Intel's PR department and suspicious 'research' funding.

My answer to AMD's PSP is the same as the Intel IME, just get rid of it. I dislike all management engines/PSP or any security hardware the user cannot control, regardless of who designed it. It is just too risky and the consequences are too big for if/when something goes wrong. Obviously nobody is perfect, but AMD have had significantly less security disasters than Intel, at least as far as I know, so I tend to trust AMD's chips a lot more than those from Intel.

[whitepines]

Re: If these exploits carry one

My answer to AMD's PSP is the same as the Intel IME, just get rid of it.

Um, you can't. Who told you it was possible?

If you remove the PSP or the IME firmware you are left with an unbootable brick by design. Don't confuse marketing BS with actual facts.

[conscience]

Re: If these exploits carry one

Err... nobody told me anything. You have got the wrong end of the stick. I was actually suggesting removing these management engine features from the design of future processors. I am well aware that they cannot simply be removed from existing chips.

As for working around the IME and unbootable bricks, I've not really looked into it as I don't use any Intel chips. Dmitry Sklyarov, published his discovery of using an undocumented method to flip a bit to effectively switch off the IME, which according to Intel was the same switch they themselves flip for governments and the security agencies as part of the US government's 'High Assurance Platform' programme. You should already know this, you appear to have posted on the news thread about it right here on El Reg back in 2017 -

https://www.theregister.co.uk/2017/08/29/intel_management_engine_can_be_disabled/

I know various people have been experimenting with removing IME, even Google engineers. No idea how successful they were, but with any luck Intel will disable it themselves if it helps make their backdoored processors any more secure than they currently are.

As for AMD, they appear to have made less mistakes than Intel have. Either way, I still trust AMD a hell of a lot more than Intel.

[eldakka]

Re: If these exploits carry one

I don't think @conscience means to just go into a current AMD/Intel processor and try to switch off/disable the PSP/IME.

I suspect they mean to stop designing processors that have PSPs/IMEs in them at all, so that future generations of processors don't have these "features".

Also, that being said, there are methods to disable most of the IME functionality, effectively turning it off immediately after boot-up, so it is only active during the initial boot-time hardware initialisation phase. Some commercial vendors offer this option, and in fact some (Dell) have had this option for a while, just not available to the general public, for special order, security-related fields usually.

[conscience]

Re: If these exploits carry one

You're correct eldakka, that is exactly what I meant.

Thanks for the links, especially the first one which was interesting and then got very interesting when it said AMD has added an option to BIOS that appears to disable the PSP. I don't know many details, the reference ultimately linked back to Reddit where a screen shot shows an ASRock motherboard with a "BIOS PSP Support" option which can be set to disabled. Hopefully this is what it sounds like, and my MSI board also has this, I'll have to have a look later.

Does anyone know more about this?

[whitepines]

Re: If these exploits carry one

Downvotes inbound, but...

That "PSP disable" switch only asks the PSP if it would be so kind as to stop doing whatever it does. Same with the IME disable (HAP bit).

I suspect Intel fed said government agencies a load of bollocks, made them feel better about HAP (it "disables" the IME!" when in fact it does no such thing), and any renegotiation in light of the actual facts of the matter would be happening behind closed doors at this point.

Possibly with a mess of high powered lawyers.

Or maybe the government is OK with a backdoor. We don't have any way to know, though I have been told repeatedly by folks in the know that not even the major world governments have IME source code, let alone PSP source code.

[Anonymous Coward]

no mention of AMD?

ARM and IBM have been notified, not AMD? What is this game they're playing?

Even if the researchers didn't care to mention AMD, it is surprising that El Reg didn't; at least to contextualize 'AMD processors are generally not believed susceptible to the Meltdown family of vulnerabilities, so may have some chance of avoiding these exploits.'

[Anonymous Coward]

Re: no mention of AMD?

At one point AMD chips do cache authorised checks or something. Not for alk steps. But there is at least one extra feature of security in their cache or speculative calc system. One of the last meltdown exploit was partially avoided due to this, and made worse on Intel chips as those did not check which thread was getting the cache (which would take longer).

[Anonymous Coward]

For how much longer are we going to allow them to get away with it?

Time to make Intel pay US for their MISTAKES.

https://www.ipetitions.com/petition/make-intel-pay-for-its-mistakes

[Anonymous Coward]

Re: For how much longer are we going to allow them to get away with it?

But they do, just keep an eye on the share price.

[Charlie van Becelaere]

"Just like Meltdown, Spectre, the MSD attacks and the SWAPGS attack discovered in the past, the LVI-LFB attack once again defeats security boundaries enforced at the silicone level," Botezatu said.

At first I thought it was supposed to be silicon, then I remembered Paris.

[Anonymous Coward]

"boundaries enforced at the silicone level"

Sounds like the technical description of a brassiere.

[Anonymous Coward]

I think ‘silicone’ is a bit of a boob.

[Pirate Dave]

One day, not to far in the future,

we'll look back fondly at the screaming fast 386's and 486's of the past, and wonder how Intel of old managed to make such fast, high-speed CPUs, and why current Intel CPUs seem to run so slowly.

[Version 1.0]

Re: One day, not to far in the future,

These days, corporate management and sales control the development of new products - ask them which they want developed, a secure processor, or a super fast processor - you know what they are going to sell...

Security? "It will be a while before anyone hacks it and in the meantime we'll sell a hell of a lot of the fast processors." Welcome to today's world.

[Anonymous Coward]

Re: One day, not to far in the future,

Sadly current processors would feel so much faster if people didn’t write such bloated code to run on them!

[Peter Gathercole]

Re: One day, not to far in the future,

For a lot of current machines, especially those on the desktop, the anti-virus protections are the biggest culprits for the perceived poor performance. If everything pulled through the network ports, or off the disk is scanned before it is used, this makes almost everything you do take much longer.

This is one of the reasons why putting Linux, especially one of the lightweight ones on a struggling Windows system makes it feel much faster.

Of course, you could turn off the anti-virus...

OK. It's Windows. Better not.

[Bronek Kozicki]

Re: One day, not to far in the future,

Well, comparing my Windows VMs against Linux ones, the biggest problem with anti-virus is not CPU or memory utilisation. It is the staggering amount of disk IO, queued every time the machine is started. And by some stupid decisions I am yet to understand (or not, since I do not feel motivated this much) this all disk IO is not just read-only. There appear to be "last accessed" timestamp that need to be updated on every bloody scanned file in the system, every day. This is madness, and not of the musical kind.

Luckily for me, Proton seems to be running every bloody game in my kids Steam library, so Windows is about to get defenestrated

[Mozzie]

Re: One day, not to far in the future,

"the biggest problem with anti-virus is not CPU or memory utilisation"

It's certainly CPU utilisation on my Windows machines. If I turn anti-virus off I get roughly 7% CPU back. Add to this the consistent fan operation under Windows on both of the laptops I run it on, idling at between 4% and 18% (Mint 0.5-1%) with no desktop applications running and occasionally even mouse jitters with background processes on a desktop i3-8100.

[Luke McCarthy]

Re: One day, not to far in the future,

Does Windows have an equivalent of "noatime" mount flag?

[Jaap Aap]

Re: One day, not to far in the future,

Yes there is something to disable last access time in windows:

"%SystemRoot%\system32\fsutil.exe" behavior set DisableLastAccess 1

[Captain Obvious]

Re: One day, not to far in the future,

Thanks for the info on Proton - was not aware of this. However, looks like it is s till a really small selection of games from Steam site and missing things like Call of Duty, etc. Just curious as what the list of Steam games looks like on your end and if I can finally get rid of more Windows systems.

[Bronek Kozicki]

Re: One day, not to far in the future,

Perhaps you are not familiar with this

Steam > Settings > Steam Play > Enable Steam Play for all other titles

[conscience]

Re: One day, not to far in the future,

@Captain Obvious

It depends which Call Of Duty game(s) or other games that you are looking to play. Some of the Call of Duty games do work with Proton, some don't. Game compatibility can be checked at protondb.com. See here for the Call of Duty games: https://www.protondb.com/search?q=call%20of%20duty

The first thing is to enable Proton for all Steam games in the settings as this adds a lot more titles. I have no idea why the suggestion was downvoted as it is the best thing to do. Not all games have been tested by Valve yet, so they aren't currently on their whitelist of tested to be compatible games, but the vast majority of games do already work with it so changing that option really helps.

And for when SteamPlay doesn't work, or it's a non-Steam title, I use Lutris (https://lutris.net/). Lutris is as easy as searching the game name and then clicking on the install button. Everything is auto-configured and if the download is available online it'll even download it for you, otherwise just point it at the installation file. Unlike Steam, Lutris can also install other gaming launchers such as EA Origin, UPlay, EPIC games store and Battle.net (which features some Call of Duty games). I posted more about it here (with some instructions): https://forums.theregister.co.uk/forum/all/2020/03/06/windows_10_insider_preview_19577/#c_3991434

You will need a Vulkan compatible GPU though, as this is used to run DirectX 10/11/12. Follow the instructions on the Lutris How to DXVK page for adding the latest drivers, WINE, and other common dependencies required for popular software.

[Peter Gathercole]

Re: One day, not to far in the future, @Bronek

I would guess that there are several things that could cause the initial flurry of disk activity. It may be that your system is set to do a scan of some sort every time it starts. Alternatively, it may be pulling into memory the scanning engine and the current virus definitions, as having this resident in memory would be a big time saver.

I don't actually run any Windows systems now (at least, not on a frequent basis, there is one that gets turned on very infrequently, so I can't relate any personal experience.

[Anonymous Coward]

Re: One day, not to far in the future,

As long as you're not a moron, you really don't need on-access scanning, or indeed any third-party antivirus.

[Pirate Dave]

Re: One day, not to far in the future,

You are, by far, over-estimating the average user.

[Pedantic]

Re: One day, not to far in the future,

Yes, in the "old days" of 30+ yrs ago, I acquired a Vic 20 and taught myself 6502 assembly programming (Ah.. happy days!) during which I acquired a word processing program called (if memory serves) Tempest. It was written using an assembler and was so blisteringly (unbelievably at the time!) fast it could scroll 100+ page of a text doc, faster than you could possibly read the screen.

I do often think of it when using various "high power" machines over the intervening years, whilst "waiting!" for something process. Given the near astronomical processing power differences between then and now, I still doo - sadly! :-) - expect every keypress to be instantaneous

[Anonymous Coward]

Re: One day, not to far in the future,

This is a joke right?

An 80486 can manage about 2 MFLOPS, while a modest i5-8500 is around 32,000 MFLOPS.

The only reason they would "seem" slow is because you're using them to do super-exponentially more things at the same time.

[tip pc]

How long before a meaningful exploit arrives

How long have we got before this is a clear and present danger to our in-house or cloud compute resources?

Someone needs to run arbitrary code on our internal / cloud compute and exfiltrate that data. How plausible is that?

All metaphorical questions.

[Claptrap314]

Re: How long before a meaningful exploit arrives

It already is. Whether these guys are ahead or behind the TLAs on this is anyone's guess.

Remember kid's, assuming your attacker is a nation-state isn't just the law--it's a good idea!

[OrangeDog]

Re: How long before a meaningful exploit arrives

If you trust everything that runs on your cloud then you're fine. If, however, you are relying on multi-tenant isolation to then it becomes an issue.

The major impact is on the big cloud providers, whose clients all have to suffer performance degradation to avoid leaking secrets to each other.

[Long John Brass]

Dumb question time

If the mitigation's are built into the compiler chains. Is there a way to turn them *OFF* for AMD based systems?

[Anonymous Coward]

Re: Dumb question time

Only if the compiler added instructions to look at the CPUID and act accordingly.

[Peter Gathercole]

Re: Dumb question time

The problem with fixing it in the compiler/assembler is that you have to trust that all the code that runs on your systems has been compiled on a patched development environment.

Even if a system has a fully patched development environment on it, if you take a binary compiled anywhere else, you have to trust that they have a fully patched environment. And you also have to have all of your libraries recompiled.

You can bet that any nefarious player who is trying to hack your machines by dropping pre-compiled binaries on you system will *NOT* use a patched environment, so you have to be super scrupulous about where the programs you use come from.

[Claptrap314]

I keep banging on this drum...

You simply cannot share a high-performance processor with someone you do not completely trust if you want to keep "your" data secure. (By "your", of course, I include your customers.)

Again, I was speaking with a company in an interview a month ago, and mentioned that for the workloads that they were discussing, it almost certainly would make sense to switching over to fully-rented machines, and turning the Specter-class mitigations off. He responded that they have already done this.

Fast, securable, shared: pick two.

[anonymous boring coward]

That's because LVI protection involves compiler and assembler updates that insert extra x86 instructions (lfence) and replace problematic instructions (such as ret) with functionally equivalent but more verbose instruction sequences.

Why would an attacker use a compiler that does this?

Did I misunderstand something about this strategy?

[LeoP]

The other wayround

Code, that is compiled with these handbrakes on is not (or at least less) susceptible to being attacked. So the deliberate compiler deoptimizations are for the victims, not the miscreants.

And why would an attacker want to slow down his code?

[Anonymous Coward]

Yet another nail in the SGX coffin?

It really seems this technology isn't really worth the trouble... I have just tried to find links to articles I had read in the past in which respectable infosec specialists made statements to that effect, unfortunately all I could locate right now is Schneier's posts and he is more moderate in his statements about SGX.

[EnviableOne]

Time to Take a RISC

Seems like the time may be approching where other architectures become appealing for hardware makers....