CPU Vulnerabilities, Meltdown and Spectre, Kernel Page Table Isolation Patches, and more

Hats off to Dell!

While it wasn't initially listed on Dell's advisory to receive the required BIOS update with the new microcode I browsed the advisory today out of curiosity. And I was greeted with a pleasant surprise: Alienware 14 A10 Bios.

Before:


After:

 

Nice.

 

The Hits just keep on coming!

"... Researchers unveil 7 more speculative execution attacks" - https://arstechnica.com/gadgets/201...-unveil-7-more-speculative-execution-attacks/

 

Spectre, Meltdown researchers unveil 7 more speculative execution attacks ( arstechnica.com)
submitted 6 days ago by Kodiack
https://www.reddit.com/r/hardware/comments/9wwef0/spectre_meltdown_researchers_unveil_7_more/

a6zj6 94 points 6 days ago
"Our org has reached a point that no one even wants to hear about Spectre and Meltdown anymore as mitigating against it has become such a pain in the ass when you have thousands of computers/servers."

Dasboogieman 81 points 6 days ago
"At this point, straight up removing Hyperthreading and speculative execution altogether seems like the only way to be secure. Though obviously doing this will knock back performance by at least a decade."

igo95862 28 points 6 days ago
"OpenBSD already did disable Hyperthreading..."

 

However, on a brighter note at the end of the article they do write this:
"Going forward, we'll likely continue to see improvements to the mitigation techniques, both to improve their performance and make them more effective. It's unlikely that we've seen the last of the speculative execution attacks, but this systematic analysis should at least mean that all the low-hanging fruit has been discovered."

Also at the end of the article they show a statement from Intel, which seems to indicate that these new attacks are already covered by their existing Spectre & Meltdown protection techniques:
" The vulnerabilities documented in this paper can be fully addressed by applying existing mitigation techniques for Spectre and Meltdown, including those previously documented here, and elsewhere by other chipmakers."
So, to me that sounds like those new vulnerabilities are already patched, or the statement could be read that Intel know how to fix them (ie "existing mitigation techniques") and instead just need to fire out a 'quick & easy' patch to fix them.

I wonder how this will play into the retpoline fixes that are upcoming for Windows 10 in 2019. The retpoline fixes are supposed to mitigate Spectre/Meltdown while giving us back the performance that we lost from the Meltdown/Spectre protections thus far.

 

Check phoronix and see those mitigations in linux kernel 4.20 has absurd perf. hits and Linus and others say they should leave the opinion to enable/disable to the user.

 

You've lost me man, that's too complicated, what do you mean & context in layman's terms?

 

I fixed a typo. I always type Linux for Linus Torvalds.
In layman's terms just like GRC's Inspectre you can disable Spectre mitigations on Linux when you want highest performance and least security whilst enabling the mitigations can result in worse, I mean really worse performance.
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Torvalds-STIBP-Comment
https://www.phoronix.com/scan.php?page=article&item=linux-420-stibp&num=1

 

You've still lost me. Can you explain to me why you linked those articles to me. Are you saying that these latest Spectre problems that have been found (the ones that jclausius linked a few posts above), have recently been fixed in Linux but for a huge performance cost? Don't leave me to connect the dots, explain what you mean. (I'm only interested in terms of a fix for these latest vulnerabilities found, we already know the performance hit of the previously found & patched Meltdown & Spectre, and I'm really mainly interested from Windows 10 angle).

 

Its not fixed because Spectre NG (NextGen) does have more variants as time progresses...
Performance hit is worse and both Intel and AMD even recommends not to use STIBP. Intel reps say the performance hit is so high that it performs really worse in some workloads.
W10 Angle: I don't know. Only time will tell! One thing is for sure anything Intel will suffer worse than AMD BullDozer.

 

Linus Torvalds Comments On STIBP & He's Not Happy - STIBP Default Will End Up Changing
Michael Larabel in Linux Kernel on 19 November 2018 at 06:21 AM EST.
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Torvalds-STIBP-Comment

"It turns out that Linus Torvalds himself was even taken by surprise with the performance hit we've outlined on Linux 4.20 as a result of STIBP "Single Thread Indirect Branch Predictors" introduction as well as back-porting already to stable series for cross-hyperthread Spectre V2 protection. He doesn't want this enabled in full by default.

All of the benchmarking I've been doing the past few days to shine the light on the Linux kernel's STIBP addition appears to be paying off. My tests have found Linux 4.20 to incur significant performance penalties in many workloads -- in fact, more so than some of the earlier Spectre and Meltdown mitigations -- and STIBP is already being back-ported to stable series like Linux 4.19.2. PHP, Python, Java, and many other workloads are measurably affected and even the gaming performance to some extent. "

"Linus Torvalds posted to the kernel mailing list on Sunday with a title of STIBP by default.. Revert?. In there he wrote: " This was marked for stable, and honestly, nowhere in the discussion did I see any mention of just *how* bad the performance impact of this was."

When performance goes down by 50% on some loads, people need to start asking themselves whether it was worth it. It's apparently better to just disable SMT entirely, which is what security-conscious people do anyway.

So why do that STIBP slow-down by default when the people who *really* care already disabled SMT?

I think we should use the same logic as for L1TF: we default to something that doesn't kill performance. Warn once about it, and let the crazy people say " I'd rather take a 50% performance hit than worry about a theoretical issue" - Linus"

 

Ok, still I'm not clear whether you're talking about just these latest Spectre problems that have been discovered over the last few days or historically since time began with Spectre. Doesn't matter, we'll see what happens.

 

I was speaking about both Old and new spectre bugs...

 

Ok, fine, we already know there's a performance impact associated with that.

 

News from Redmond OS patch mess factory

KB4465065 Windows 10 1809 and Server 2019 27.11.2018 Intel Microcode has been updated Deskmodder.de | Nov 27, 2018

Microsoft has updated the Intel microcode update. As always, this is Specter Variation 3a, Specter Variation 4 and L1TF. Which CPUs have been added, I could not find out yet.

The orginal source... https://support.microsoft.com/en-my/help/4465065/kb4465065-intel-microcode-updates

 

Microsoft a little bit slow to release this latest microcode, I've been running C6 microcode since July this year (released through a BIOS update from my motherboard manufacturer). C6 is definitely no worse in terms of performance than C2 (the previous version), it seems slightly better in fact, but splitting hairs really. I'm talking Skylake CPU here.

 

It’s ok they are slow. The standalone update is targeted at Windows 10, version 1809 (Windows 10 October November 2018 Update) so add in more patches into their latest OS mess isn’t the smartest. Already screwed up as it is.

 

They are indeed quite slow, but I think it's good that they include microcode updates in the OS because a lot of systems don't necessarily receive BIOS updates with microcodes, so this is a way for those folks to get the Spectre protection that they wouldn't otherwise have. They should test out releases of Windows 10 more thoroughly though, and not rely on the general public to be beta testers, that's for sure!

 

As an optional stand-alone patch.., Yees. Forced... No!

 

I see what you mean, but I suppose the majority of people that use Windows don't know enough about it to make the decision to apply or not to apply the patch, so by making it 'default' they're simplifying the experience at the same time as providing security protection. I suppose they could provide clear explanations in an optional patch so that people can make their own decisions re to apply or not to apply, and as a fairly tech savvy person that would suit me better, but I'm not sure when it comes to the majority of the user base.

 

Forced inside the cumulative update is a bad idea. All will get it if they want or not. See... If you don't want it through running Win update and instead prefer to install full patches manually by yourself you will have it whatever you will or not.

 

I know what you mean, it's the same point you made, so the same counter argument exists.

 

For skylake its still C6 microcode according to platomav repo at github. https://github.com/platomav/CPUMicrocodes/tree/master/Intel
CPUID is cpu506e3.

 

Yes, C6 is the 'new' microcode for Skylake, it was C2 in previous Windows microcode updates. Intel released C6 microcode ages ago though, for instance I had it since July through my BIOS motherboard manufacturer.

 

With all the patch mess from Redmond Morons it's easy to think you know what's correct.

The old microcode patch Update from 20.08.2018 contain last and the correct Intel microcode for Skylake(0xC6). But the newer and latest patch update from Micro$haft Morons - their last working released OS (1803) - is in fact the older 0xC2

http://forum.notebookreview.com/threads/windows-10-redstone-4.813941/page-51#post-10795356

 

I think I had it right, you linked in your post that v1809 has now been updated with C6 microcode, and I knew that v1803 was on C2 microcode when I was using it previously (which is what you also showed me in your own post that you linked to me above). Are you saying that v1803 has currently not been updated with the latest C6 microcode yet?

 

The C6 come with KB4346084 Intel Microcode Updates for Windows 10 v1803 - November 27. But as I showed... MicroSoft first released C6 in Aug and downgraded it in the last (previous) patch in Sept ( C2 ).

 

Ok, fine, not sure why you quoted my post earlier insinuating that I didn't know what was going on, when all I had said was: "C6 is the 'new' microcode for Skylake, it was C2 in previous Windows microcode updates. Intel released C6 microcode ages ago though, for instance I had it since July through my BIOS motherboard manufacturer.".

We're on C6 microcodes now via Windows updates, that's the news.

EDIT: My main point of why I started posting here in response to your news story you posted on Microsoft issuing new microcode updates, was that I've not seen a performance decrease from using the C6 microcode in comparison to the C2 microcode that was being used before - so people don't have to worry about that change - that's my reason for posting. Also, that I think it's good that Microsoft are issuing these updates, because you can't guarantee on motherboard updates & also that people will apply them.

 

Wasn't meant as insinuating against you or anybody. Sorry. All I tried to say.... Micro$haft screwed up with previous patch and not all know about this. Again sorry, sir.

 

Ha, ok, that's not how I read it, but doesn't matter, I know what you mean now - Microsoft released C6, then pulled it back to C2, then released C6 again. Ha, you know you don't have to call me sir!

 

we'll call you Mr. Robo Boss.
I don't have any ucodes installed by microsoft.

 

Ha, nooo, don't be silly!

 

Yes Robo boss, I mean Robo999999.

 

6:41 - Linus Torvalds: After big Linux performance hit, Spectre v2 patch needs curbs
http://forum.notebookreview.com/thr...18-my-way-or-the-huawei.826074/#post-10827088

Linus Torvalds: After big Linux performance hit, Spectre v2 patch needs curbs
Patch is causing as much as a 50 percent drop in performance in some Linux workloads.
By Liam Tung | Security | November 20, 2018 -- 12:47 GMT (04:47 PST)
https://www.zdnet.com/article/linus...performance-hit-spectre-v2-patch-needs-curbs/

"Major slowdowns caused by the new Linux 4.20 kernel have been traced to a mitigation for Spectre variant 2 that Linux founder Linus Torvalds now wants restricted.

Spoiler: Details...

As noted by Linux news site Phoronix, the sudden slowdowns have been caused by a newly implemented mitigation called Single Thread Indirect Branch Predictors (STIBP), which is on by default in the Linux 4.20 kernel for Intel systems with up-to-date microcode.

STIBP is one of three possible mitigations Intel added to its firmware updates in response to the Spectre v2 attacks. Others included Indirect Branch Restricted Speculation (IBRS), and Indirect Branch Predictor Barrier (IBPB), which could be enabled by operating-system makers.

STIBP specifically addresses attacks against Intel CPUs that have enabled Hyper Threading, its version of Simultaneous Multithreading (SMT)

Phoronix's benchmarks comparing Linux 4.20 with STIPB enabled show that the mitigation on some application workloads has a severe impact on performance.

With STIBP enabled, Phoronix's high-end Xeon Gold server also goes from being the fastest server to slower than AMD's previously lower-performing EPYC-based server.

Because of these slowdowns Torvalds' on Sunday posted a message demanding STIBP no longer be enabled by default in the kernel, especially since an existing option is to disable SMT.

"When performance goes down by 50 percent on some loads, people need to start asking themselves whether it was worth it. It's apparently better to just disable SMT entirely, which is what security-conscious people do anyway," wrote Torvalds.

"So why do that STIBP slow-down by default when the people who *really* care already disabled SMT?"

Researchers earlier this month made the same argument against SMT after revealing the PortSmash side-channel vulnerability, which affects all Intel CPUs that support Hyper-Threading.

The researchers noted that "security and SMT are mutually exclusive concepts" and encouraged users to avoid chips that feature SMT. An earlier attack called TLBleed prompted the OpenBSD project to disable support for Intel Hyper-threading.

Torvalds said the code didn't need to be fully reverted, but the behavior that STIPB needs to be "unconditionally" enabled does need to be reverted.

"Because it was clearly way more expensive than people were told," noted Torvalds.

 

Am I right in thinking that this is the same protection that is not enabled by default in Windows 10, but can be enabled manually in Windows 10 as long as you have the latest CPU microcode? This is the protection that is too performance costly, and therefore wasn't enabled by default in Windows 10?

 

Thankfully one of the latest BIOS update allowed to disable HT completely on my laptop's puny i5-6200u, and that's exactly what I did. Had to re-enable HT. \=

Still makes me sad - since the beginning of 2018 the machine was getting slower and slower thanks to Spectre & Meltdown mitigations, now another hit - all the while I multitask on it very heavily, and not willing to part with it tbh.

 

I don't think it's necessary to disable hyperthreading. I suppose it depends what you use your laptop for, and if you are well informed that you're likely to be exposed to critical threats if you leave it enabled. It's certainly not accepted that in the consumer space that it's necessary to disable hyperthreading.

 

I actually re-enabled it within couple hours after disabling. It was simply unbearable, the CPU displayed very high usage barely doing anything. )'=

 

Yeah. I disabled those mitigations because my CPU performed like crap and deviated heavily than advertised cpu performance.

 

Analyzing Core i9-9900K Performance with Spectre and Meltdown Hardware Mitigations Anandtech.com | December 3, 2018

 

Stupid questions: Wouldn't it be easier to not allow rogue software to run on secured systems to begin with? I mean all this fancy 20 word random alfanumerical passwords we are being force to use this days mean jack, if the access computer has simple keylogger running in the background, or you're fooled to log on to spoofed website. Spectre and Meltdown could be a big issue for financial institutions and other high security computer operators, but most security breaches are usually low tech. I can't find details on how exactly this hacks work, but there has to be better solution than disabling HT and SMT especially for lower security home users. For example I have multiple laptops, so I could set up one for secure bank and CC transactions, but leave my gaming computer alone. BTW does it mean I should not take any more security updates from MS or Intel to avoid my computer to loose half of the performance? Seems to me protection from thread is worse than the thread itself.

 

Exposing secured systems to risks could be unavoidable for some. Many if not most people have single computer and single smartphone.

 

" Thread is nothing to fear, more than Thread itself." - @pete962

A detailed threat of a vulnerability is a warning to be aware, you can decide to take action or not.

"Forewarned is forearmed" - Advance warning provides an advantage.

"Taking heed of technical fore-warnings is always a good idea, it's much nicer to patch a vulnerability than suffer the long term fallout and recovery from not doing so." - Been there done that, wearing the T-shirt right now... System Administrator.

"Rather than bump around in the dark, turn on the damn light. " - The Light Switch

"There's always reason to be reasonable, but it's much easier to stick your head in the sand." - The semi-reasonable Ostrich.

"That's what makes life fun, you decide on your own level of Drama." - Drama Queens the World over...

 

And, that's why security updates and mitigations are installed by default on Windows, Macintosh, Android, iOS, etc systems, outside the control of the individual users decision making process.

Linus Torvalds is saying not for Linux, as it's a server / workstation OS and the distro's shouldn't burden the System Administrators with this - they are the ones dealing with the systems management in bulk instead of individual users.

That's not so much the case any longer - lots of individuals are installing Linux as well as professional System Administrators, and what they could do is make it an installation choice to accept / deny at install / update [upgrade] so as to at least alert the installer as to what the mode of mitigation control is default and optional.

Time will tell...

 

Showing that, except for the HT vulnerability, performance hits in gaming (the only thing stupid users care about, hence the use of those to say CPU performance rather than examining other use cases) are negligible and the mitigations should be implemented.

Yes, controlling software ran on the machine is easiest, but due to Java exploits, etc., it is easier said than done, depending on the machine.

As to SMT/HT problem exposing memory, they tried a solution and you take 50% performance hit in some workloads, whereas turning off SMT/HT is around 30%. This is why Linux pulled the patch from distribution, because if you are worried about it, you are better served by turning off HT/SMT than patching it, at least until another solution is found. Trust me, they are looking for other mitigations to impact performance less. This is why Microsoft is adopting Google's retpoline solution over Intel's solution for the next version of their OS coming out spring of 2019, as it has a lower performance impact.

Simply put, if there was a better solution, it would be implemented or planned for implementation. To date, there isn't a better solution. Meanwhile, it is likely only nation states with the resources to implement some of these exploits with any real success.

Sent from my SM-G900P using Tapatalk

 

In case you're not already sick of Spectre... Boffins demo Speculator tool for sniffing out data-leaking CPU holes
First proof-of-concept, SplitSpectre, requires fewer instructions in victim
By Richard Chirgwin 7 Dec 2018 at 23:59
https://www.theregister.co.uk/2018/12/07/splitspectre_attack/

" Analysis You've patched your Intel, AMD, Power, and Arm gear to crush those pesky data-leaking speculative execution processor bugs, right? Good, because IBM eggheads in Switzerland have teamed up with Northeastern University boffins in the US to cook up Spectre exploit code they've dubbed SplitSpectre.

SplitSpectre is a proof-of-concept built from Speculator, the team's automated CPU bug-discovery tool, which the group plans to release as open-source software. Their work is described here in an academic paper emitted earlier this week.

Andrea Mambretti, told The Register that he and his Speculator coauthors – Engin Kirda, William Robertson of Northeastern University and IBM's Matthias Neugschwandtner, Alessandro Sorniotti, and Anil Kurmus – aren't trying to scare the world with yet more chip vulnerability exploits, but rather want to prise open the secrets of CPU microarchitecture.

The big silicon design houses keep details of the inner mechanisms of their processors under tight wraps, which means discovering speculative execution flaws and suchlike requires a non-trivial amount of reverse-engineering.

Thus, Speculator tries to automate that discovery process. Spec-ex is one of the key drivers of processor speed, which is why CPU engineers and their bosses don't like to talk about it, in case they spill any secrets to competitors.

Mambertti explained to The Register Speculator came about from “the analysis of common elements of [speculative execution] attacks," and should "help the analysis of new and old attacks.

“SplitSpectre is the result of our analysis, and thanks to Speculator, we could precisely measure the characteristics required for an attack to succeed as well as study general behaviors of the CPU during speculation that before were not known or documented.”

SplitSpectre: If you patched, relax
Speculator was able to find a “novel variation" in the techniques needed to exploit Spectre variant 1 vulnerabilities in processors. These are those flaws you've heard so much about, the ones that can be abused by dodgy applications and malware to leak passwords, crypto-keys, secrets, and other data from the computer's memory that should be off-limits.

This particular variation was dubbed SplitSpectre, and it differs from previous exploits by “requiring a smaller piece of vulnerable code available in the victim’s attack surface.” Spectre exploitation relies on specific sequences of code running in the software you're trying to spy on. SplitSpectre requires a shorter chain of instructions in its victim, which means code thought to be invulnerable to Spectre may actually be snooped on by this new technique.

Having said that, today's mitigations for Spectre should thwart this version of SplitSpectre. Future versions may be more successful, or "viable," as the researchers put it. It is a proof-of-concept of Speculator, after all, and is written in JavaScript to run in Mozilla's SpiderMonkey JS engine.

One key point is that SplitSpectre can snoop on the underlying JavaScript engine, meaning it could in theory peek at private and sensitive data used by other JavaScript code running at the same time on the engine, say, in other tabs within a browser.

One defense mechanism is to, therefore, securely sandbox browser tabs and windows so that malicious JavaScript cannot snoop on other pages and scripts via Spectre, which is what modern web browsers tend to do now. Again, the point of SplitSpectre is to demonstrate how Speculator can explore and potentially uncover future weaknesses in CPU microarchitectures.

The team's paper has an illustration of the SplitSpectre technique – pictured right – and explained the nitty-gritty: “A V1 gadget consists of a bounds check and two array accesses ... In order to mount a regular Spectre V1 attack, we would require a complete Spectre V1 gadget available in the JavaScript engine. The intuition behind SplitSpectre permits us to relax this requirement and only require the first half of a V1 gadget, i.e. the bounds check and the first array access.”

Mambretti stressed it's not a browser-reliant exploit, nor reliant on JavaScript. It pretty much affects code running concurrently on a shared interpreter. JavaScript was chosen because it can be embedded in malicious web pages or in emailed documents by miscreants attempting to pull private data out of the underlying environment. It's a relatively realistic attack scenario, in other words.

“We are only talking about SpiderMonkey and not browsers,” he said in an email. “SplitSpectre crosses the privilege boundary, between attacker-controlled JavaScript and the runtime environment, within the SpiderMonkey engine.”

The paper added: “The attack works ... we leak a string of ten characters with a success rate of over 80 per cent, and we leak the full string with a success rate of 10 per cent.”

Mambretti emphasized that a system fully patched against Spectre would be immune to SplitSpectre as it stands. The exploit is not tied to any particular CPU architecture, though the boffins tested their JavaScript on Intel Broadwell and Skylake CPUs, and AMD Ryzen chips. The research didn't specifically look at Arm-compatible components.

We pinged AMD and Intel for comment. AMD insisted its existing defense mechanisms block SplitSpectre. Intel declined to comment. We understand, though, Chipzilla's engineers are confident today's software mitigations defeat SplitSpectre.

Fuzzing the CPU's performance counter, for fun, and speculative execution
As Mambretti mentioned, the biggest road-bump spec-ex researchers face is that CPU vendors don't publish enough detail on their microarchitectures. The boffins decided they wanted a “tool whose purpose is to reverse-engineer the behaviour of different CPUs,” so they looked at the signals processors give the outside world that could identify two things: when spec-ex is happening, and, much more difficult, how to use that information to siphon data from memory holding sensitive information.

Speculator's architecture - click to embiggen

They drilled down on an interface CPU vendors provide to help optimise software: hardware performance counters.

The Speculator paper noted that these counters reveal “microarchitectural state changes such as cache accesses, retired instruction, and mispredicted branches,“ which can be used to "accurately measure microarchitectural state attributes associated to the speculative portion of the execution of user-supplied snippets of code.”

In other words, these counters keep track of how hard the CPU is working behind the scenes, and what exactly it may be up to, so as to maximize the rate of execution; this information can be used to pull off Spectre-based attacks. The kinds of thing Speculator observes in order to sniff out exploitable spec-ex weaknesses include:

• Which code snippets are speculatively executed
• What triggered spec-ex to start and stop
• How specific instructions affect its behavior
• Which security boundaries prevent spec-ex, for example the boundaries between kernel and user mode, and between a runtime engine and interpreted code
• The consistency of CPU behavior within the same architecture or across different architectures.

Running Speculator showed Mambretti and his collaborators how to craft their new technique, SplitSpectre. They focused on instructions that are speculatively executed, but not retired, because those instructions provided insight into architectural side effects, side effects that formed a side-channel from which to lift bytes of private data." Comments PDF

 

How is this different from writing virus itself and releasing it? This Spectre and Meltdown exploits would never been found and never used without academic support, long research and funding. If those researchers are so clever, why don't they get a job at Intel or AMD and actually create processors that are better and faster than what we have, instead of doing advanced research for criminals basically.

 

Are you an idiot? You just argued that people should just stop looking for vulnerabilities as a way to fix problems before exploitation, which would leave it solely for criminals and nation States to know and exploit. You know who found meltdown and spectre originally? A new Google employee told to sit down with Intel's white papers and find ways to speed up processing. At the same time, a couple academics also found it. Once made public that a speculative execution issue may be possible through a leak, a read student found it within a day. Do you think the resources of nation States didn't know?

Truth is security through obscurity doesn't work. It only buys time. Fixing the problems in the architecture works. This is why the Intel management engine had to be gutted for Intel to be used by NSA, why voting machines have been shown to be compromised in so many ways, and very easily at that, yet we do nothing, etc. Open source doesn't guarantee anything either, as the NSA pays for zero days, then don't report them so they can exploit them rather than making it more secure.

Yet your solution is sit back and stop looking, just let your security be vulnerable? Are you one of those IT is with an AWS bucket that isn't password protected? Sure sounds like it. Lol!

Sent from my SM-G900P using Tapatalk

 

They won't hire them because NONE want to market their products are defective and Intel took the trade-off to get highest performing CPUs and at the same time it was a risk they were willing to take.
Then again bounty programs always target a device with highest market share for example Intel. Some variants does affect AMD and ARM but not as severe as Intel.
What if, those researchers ship or install Spectre like malware to infect millions of devices w/o people or security company aware of it and they could have become billionaires in a night. But they didn't do that and instead went to Intel and others to notify about the bug which gave Intel/AMD/ARM to make patches to get around it.

No one knew the CPU were becoming a backdoor on the influence of NSA and similar agencies to spy on users.
In near future we might find horrible exploits at hardware level where only remedy is to ditch the hardware to avoid performance issues.
I feel researchers finding methods to speedup processing accidentally discovered a flaw that affects millions of devices is a great thing and they notified Intel about the issue.
I hope researchers find Spectre like issues and even WPA2 KRACK exploit along with fixes to keep both tech savy and non tech savy people safe from targeted attacks.

 

Those researchers at IBM and Northeastern University are looking to make more secure systems by digging in and finding out if mitigations are working. The test tool to verify secure operation isn't a virus, any more than an anti-virus is a virus.

As a test tool, just the same as any other tool, it can be used by good and bad actors, but you can't ban a tool or the research into it in a misguided effort to stop bad actors, they will get or make such tools for themselves and then the good guys won't have the tools needed to verify the security of the systems they manage.

The vulnerabilities exist outside of any good or evil scenario, and discovery first by the good guys - with mitigations with protection and discovery tools will more likely happen outside the realm of their creation, that just how it works historically.

The intended role of the software or hardware is where the creators focus, and funding for tangential investigations of issues that are thought of during the creation are likely not available, so outside resources are put to the task of discovery - if we are lucky - even if the vulnerabilities are not "obvious" for 20 years - or if the focus of funding takes that long.

It may seem "dangerous" for the good guys to question software / hardware integrity, but without those that do we may never find out just how much in danger we all are from the bad guys looking for an angle into our systems.