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 …
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?
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.
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.
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.
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.
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.
@"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.
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.
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 & 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.
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".
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.
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.
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.
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?
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.
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.'
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).
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.
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.
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
"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.
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.
@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.
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.
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
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.
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.
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.
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.
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?
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
