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

I recommend you try Linux 18.04 LTS version from (X,K,E)Ubuntu/Debian/Mint. Simply you get 10C reduced temps than W10 or 3C-5C lower than w7/8.1.x

 

So I mentioned earlier that the only known spectre/meltdown attacks don't actually use the vulnerabilities, but rather are phishing attacks disguised as mitigation solutions. Has this changed? Are there known exploits at this point? Mostly wondering because I want to see how long the gap between a real exploit and the pending BIOS updates ends up being.

 

What a mess. We've gone from the initial vulnerability announcement to half-baked Windows updates (some of which broke the OS on AMD systems) to microcode updates that caused reboots and BSODs on all platforms to updated versions of the previously mentioned Windows updates (with a degree of confusion about whether the new updates replace the older ones for all systems or just for affected AMD systems) to OEMs pulling their BIOS updates to Intel announcing a beta microcode which allegedly fixes the reboot issue to Microsoft releasing a small update that toggles off the Spectre protection from the Intel microcode update to mitigate the reboot/BSOD issues in the interim.

I'm sitting here on the sidelines just having a hell of a time keeping up.

 

Microsoft works weekends to kill Intel's shoddy Spectre patch
Out-of-band patch may assuage user anger over Intel crudware, closed-club disclosure process
By Richard Chirgwin 29 Jan 2018 at 01:18

"Microsoft has implemented Intel's advice to reverse the chipmaker's Spectre variant 2 microcode patches.

Redmond issued a rare weekend out-of-cycle advisory on Saturday here, to make the unwind possible.

Intel's first patch was so bad, it made many computers less stable, sending Linux kernel supremo Linus Torvalds into a justifiable meltdown last week.

Chipzilla later withdrew the patch, but it had made its way into a Microsoft fix, which the Windows giant pulled on Saturday.

“Our own experience is that system instability can in some circumstances cause data loss or corruption,” Microsoft wrote, adding “We understand that Intel is continuing to investigate the potential impact of the current microcode version and encourage customers to review their guidance on an ongoing basis to inform their decisions.”

This applies only to the Spectre processor vulnerability patch, Microsoft emphasised: “Application of this payload specifically disables only the mitigation against CVE-2017-5715 – 'Branch target injection vulnerability.'”

It noted that as far as anyone knows, nobody's yet weaponised Spectre variant 2 in the wild.

LinuxConf panel: Embargo a 'crap-fest'
The handling of Spectre and Meltdown received sharp criticism at last week's LinuxConfAU in Sydney, with Linux Foundation technical advisory board member Jonathan Corbet complaining of the ongoing secrecy about events between the first private reports of the bugs and their eventual disclosure (which The Register broke on January 2).

Instead of the disclosure processes used for most vulnerabilities, Corbet said, “This disclosure process was handled very differently,” and nobody's explained why.

Corbet later added “I'd like the industry to end at least that piece of it, so that we can get the whole story out there, and figure out how to do better the next time around”.

Developer Jess Frazelle said disclosure could be improved by “not having an absolute ****-show of an embargo”, while Katie McLaughlin added that only big cloud providers were in the know: “It seems to be like an exclusive club as to whether you know or don't know, and it's not really clear the lines of who should be informed.”

A video of the conference panel is below, for your viewing pleasure."

Panel: Meltdown, Spectre, and the free-software community
Published on Jan 25, 2018
Jonathan Corbet, Andrew 'bunnie' Huang, Benno Rice, Jess Frazelle, Katie McLaughlin, Kees Cook
http://mirror.linux.org.au/linux.conf...
http://lca2018.linux.org.au/schedule/...
The Meltdown and Spectre vulnerabilities raise a lot of questions about how our hardware works — and how we respond when things go wrong. This panel will discuss these vulnerabilities, how they affected us, and what we would like to see done differently the next time around. The panel consists of Kees Cook, Andrew 'bunnie' Huang, Jessie Frazelle, Katie McLaughlin and Benno Rice; it will be moderated by Jonathan Corbet.

This talk was given at Linux.conf.au 2018 (LCA2018) which was held on 22-26 January 2018 in Sydney Australia.

linux.conf.au is a conference about the Linux operating system, and all aspects of the thriving ecosystem of Free and Open Source Software that has grown up around it. Run since 1999, in a different Australian or New Zealand city each year, by a team of local volunteers, LCA invites more than 500 people to learn from the people who shape the future of Open Source. For more information on the conference see https://linux.conf.au/

#linux.conf.au #linux #foss #opensource

 

You can't ignore Spectre. Look, it's pressing its nose against your screen
Strap yourself in, this ride won't be over for a long time yet
By Trevor Pott 29 Jan 2018 at 10:02
https://www.theregister.co.uk/2018/...spectre_pressing_its_nose_against_your_glass/

"The Spectre processor design vulnerability is here to stay. Even if you choose to ignore it, the problem still exists. This is potentially a very bad thing for public cloud vendors. It may end up being great for chip manufacturers. It's fantastic for VMware.

Existing patches can fix Meltdown, but only seem to be able to mitigate Spectre, not fix it. By many accounts, we'll be playing whack-the-vulnerability with Spectre until at least the next generation of silicon.

The definitive paper on Spectre says: "While makeshift processor-specific countermeasures are possible in some cases, sound solutions will require fixes to processor designs as well as updates to instruction set architectures (ISAs) to give hardware architects and software developers a common understanding as to what computation state CPU implementations are (and are not) permitted to leak."

A number of security experts I have spoken to confirm that the Spectre problem has not gone away, nor is it going to any time soon. There is some concern, however, about the messaging that is emerging around this vulnerability.

A great many individuals – not only those who work for Intel – have been putting a lot of time recently into telling everyone that we should calm down, not worry about Spectre, and simply continue with business as usual. There are patches, they say, and even if those patches cause problems now, that will be addressed soon.

It's not quite that simple, and Spectre may ultimately change computing forever. In the short term, it means a lot of pain for some pretty big companies.

Spoiler: Details...

Cloud replacement
One can apply a patch for Meltdown, take the performance hit (which can be 30 per cent or more for some workloads), and then never think about Meltdown again. This isn't ideal, but from a risk management standpoint it's fire and forget.

Spectre is a different story. Even with microcode updates, Spectre can't be completely fixed without significant changes to the architecture of modern CPUs, and that means hardware replacement. Unfortunately, the CPUs we all need to buy in order to guarantee that we're not affected by Spectre don't actually exist yet.

This isn't exactly good news if you're a public cloud provider that is trying to build enough trust to absorb a significant percentage of the world's regulated workloads. It's one thing for software vulnerabilities to exist, it's another to have known hardware vulnerabilities. That's not good when you're selling the concept of shared infrastructure.

Even if public cloud providers wanted to replace some or all of their systems with CPUs that don't have the Spectre hardware bug, they can't. Yes, older Atom processors and other in-order CPUs aren't affected by Spectre.

Unfortunately, none exist which are as fast as the out-of-order Xeons that power our servers. In fact, there probably aren't enough in-order x86 CPUs on the planet to replace the requirements of even a tier-two public cloud provider. As soon as realistic replacement chips are produced, complete replacement cycles will most likely occur. The legal uncertainty places pressure on public cloud providers to get this Spectre issue put to bed once and for all, if for no other reason than risk management.

That's great news for Intel – after all who else are you going to buy from– but it's non-optimal for the public cloud providers. Unexpected hardware refresh cycles take time, money, and affect margins. Wall Street doesn't like things that affect margins.

Forget what they taught you in kindergarten; sharing is bad
Spectre can theoretically allow code operating in a VM to read code in the cache of the physical CPU. If anyone figures out how to exploit it then it can allow someone executing code in one VM to peek into what's running in memory of another VM.

Because cloud providers are designed to offer shared resources, nothing stops a malicious actor from executing code on VMs they hire from the cloud provider. This could let them get access to data being crunched by other VMs which the malicious actor didn't hire. This means that – hypothetically, at least – every workload running in the public cloud that isn't on a dedicated host is vulnerable to random malicious actors.

State-sponsored actors absolutely have the resources to produce malware to exploit Spectre. Let none of us pretend that they don't. From a legal standpoint, this may not be a huge problem. It's unlikely any judge will expect the average company to defend themselves against nation states.

Unfortunately, nation states likely aren't the only ones with the resources to exploit Spectre. Consider the theft of cryptocurrency over the years. At today's prices, since 2010, multiple billions of dollars worth has been stolen. In 2017 alone, $225m worth of the Ethereum coin was stolen. That's not counting all the various Bitcoin thefts, or of other minor cryptocoins. A quick Google for Bitcoin thefts in 2017 shows that we could easily be looking at hundreds of millions of dollars there as well.

Add in the steady payday of ransomware over the past few years and the net result is malicious actors with significant digital crime experience and potentially a lot of money. Enough money to make very serious plays for Spectre zero days.

Yes, Spectre patches exist that mitigate the problem. And as soon as a new attack is discovered, patches will emerge to mitigate those attacks too. The problem is that everyone now knows where to look for guaranteed exploits, and there are likely to be more people trying to come up with new attacks than there are people trying to create new mitigation patches.

Your responsibilities
The above needs to be considered in the context of increasing regulatory pressure. The GPDR looms large. Canada is moving towards mandatory breach notification. Australia is already there, with some US states joining in as well.

Some of the newer regulatory regimes aren't satisfied with just patching and pretending everything is OK. They basically say that organisations have to do everything within their power to protect against any flaws that they reasonably should have known existed. The more we collectively talk about Spectre – and the tech press isn't giving up on this any time soon – the harder it becomes to stand up in front of a judge and say: "Your honour, burying our heads and engaging in business as usual was the best practice at the time."

It is here that the real dichotomy emerges in discussions about Spectre.

Political realities
Public cloud providers, Intel, and software vendors that exist primarily in the cloud ecosystem are largely hoping nobody pulls a Max Schrems and challenges this in court until they can replace CPUs. They want to promote calm in order to ensure that the adoption of public cloud services continues uninterrupted.

And the public clouds matter. Shared infrastructure is increasingly dominant, and projected by many of the top analyst houses to host the lion's share of enterprise IT by 2020.

Note that this doesn't mean the majority of workloads. What it means is that enterprises are relying on the public cloud to handle the really large workloads. Big Data analytics, machine learning, artificial intelligence: the sort of workloads that I lump together under the term Bulk Data Computational Analysis (BDCA).

The key there is "computational": these are CPU and GPU-heavy workloads. And they often operate on highly sensitive datasets, such as medical data. Public cloud companies don't want to lose this work, and if we're being perfectly honest about it, there aren't enough trained BDCA IT operations people to allow enterprises to bring these workloads in-house anyways.

As a result of the above, frank discussions about Spectre are politically fraught territory. This was made clear early on when CERT deleted their note for one of the two Spectre CVEs that said the solution is to replace CPU hardware. The original wording was: "Underlying vulnerability is caused by CPU architecture design choices. Fully removing the vulnerability requires replacing vulnerable CPU hardware."

Reality didn't change between the initial posting of that recommendation and its retraction. Fully fixing Spectre still requires replacing the CPUs. The thing is, there's nothing any of us can do about that right now, and CERT's original recommendation could lead to anxiety.

Anxiety about Spectre is considered by many to be a very bad thing. There is an argument to be made that anybody rocking the boat with anything other than "remain calm" messaging is a threat to US national security. The public clouds are not only a major economic consideration for them, but they are increasingly a strategic asset.

Having companies and governments around the world suddenly decide that they are going to pull their data off of US servers run by US companies that must obey US subpoenas is not something the US encourages.

Your own toys
There is no reason for doom and gloom, however, as public cloud providers already have the solution to this problem to hand. The rental of bare-metal systems under the control of a single organisation is the ultimate mitigation against Spectre.

Yes, the Spectre vulnerability is still there, buried underneath it all. But malicious actors can no longer simply rent time on the same physical box that your workload is executing on, and try to get at your encryption keys, passwords, and other goodies. The bad guys would have to break in the old-fashioned way: through your layers of firewalls, application security and other defence-in-depth measures.

In many ways, VMware on AWS may be just be the ultimate solution here. After all, it is dedicated hardware to just you. VMware on AWS isn't alone – Microsoft, for example, rolled their own version – and renting dedicated servers from service providers has been a thing for some time.

I find it deeply ironic that perhaps the greatest reason for organisations to seriously consider VMware on AWS isn't exactly something VMware can get out there and start loudly advertising. Don't expect to see any "use VMware on AWS because Spectre means that shared infrastructure is a bad plan for sensitive workloads and Intel is going to take a couple of years to get the world replacement chips" whitepapers. VMware can't really afford to pee in either Amazon's or Intel's Cheerios.

Other than Google, there may not be anyone who can.

Defence in depth
For most, the above is an abstract discussion. None of us can really do anything about Spectre other than patch. Public cloud adoption programs are large undertakings that move slowly, and they aren't easily slowed or halted. In the time it would take most organisations to bring their workloads back in-house, the hardware replacement will have taken place.

But Spectre may cause security-conscious organisations to delay implementation of new public cloud migrations. It may also cause discussions to move away from shared infrastructure and towards dedicated servers. If done on a large enough scale that changes cloud economics, and could even have a noticeable impact on global electricity consumption.

Defence in depth is ultimately the only real choice any of us have. Some vendors may do well here. HyTrust (formerly DataGravity) is one vendor I expect is going to get a second look from a lot of organisations. Their elevator pitch has always been about enforcing security-based policies across private and public clouds, and automating security just got a whole lot more important for everyone.

But all the firewalls, network microsegmentation, policy automation, Role Based Access Controls (RBAC), and so forth that we layer on top of our networks guarantees nothing. Our best bet is proper holistic IT, and some serious investment in automated incident response.

Part of defense in depth now requires that we pay careful attention to which workloads we place on shared infrastructure and which workloads we insist must operate on nodes only our organisation uses. We must now assume that everything is compromised. Even the CPUs upon which our workloads run."

 

Intel alerted Chinese cloud giants 'before US govt' about CPU bugs
'We certainly would have liked to have been notified of this' says Homeland Security
By John Leyden 29 Jan 2018 at 19:38
https://www.theregister.co.uk/2018/01/29/intel_disclosure_controversy/

"Intel warned Chinese firms about its infamous Meltdown and Spectre processor vulnerabilities before informing the US government, it has emerged.

Select big customers – including Lenovo and Alibaba – learned of the design blunders some time before Uncle Sam and smaller cloud computing suppliers, The Wall Street Journal reports, citing unnamed people familiar with the matter and some of the companies involved.

The disclosure timeline raises the possibility that elements of the Chinese government may have known about the vulnerabilities before US tech giant Intel disclosed then to the American government and the public.

Spoiler: Details...

The Meltdown and Spectre chip flaws were first identified by a member of Google's Project Zero security team shortly before they were independently uncovered and reported by other teams of security researchers. "Intel had planned to make the discovery public on Jan. 9... but sped up its timetable when the news became widely known on Jan. 3, a day after U.K. website The Register wrote about the flaws," the WSJreports.

Intel worked on addressing the vulnerabilities with security researchers at Google and other teams that uncovered the processor vulnerabilities as well as PC makers – specifically, the larger OEMs – and cloud-computing firms. Those informed included Lenovo, Microsoft, Amazon and Arm.

The WSJ omits any mention of when notification was made to Lenovo et al, but a leaked memo from Intel to computer makers suggests that notification of the problem for at least one group of as-yet unnamed OEMs took place on November 29 via a non-disclosure agreement, as previously reported.

Lenovo was quick out the gate on January 3 with a statement advising customers about the vulnerabilities because of work it had done "ahead of that date with industry processor and operating system partners."

Speculative
Alibaba Group, China's top provider of cloud services, was also notified ahead of time, according to a "person familiar with the company." An Alibaba spokesperson told the WSJ that the notion the company may have shared threat intelligence with the Chinese government was "speculative and baseless". Lenovo said Intel's information was protected by a non-disclosure agreement.

It is a "near certainty" that Beijing was aware of information exchanged between Intel and its Chinese tech partners because local authorities routinely monitor all such communications, said Jake Williams, president of security firm Rendition Infosec and a former National Security Agency staffer.

An official at the US Department of Homeland Security, which runs US CERT, said it only learned of the processor vulnerabilities from early news reports. "We certainly would have liked to have been notified of this," they added.

Rob Joyce, the White House's top cybersecurity official, publicly claimedthe NSA was similarly unaware of what became known as the Meltdown and Spectre flaws.

Because they had early warning, Microsoft, Google and Amazon were able to roll out protections for their cloud-computing customers before details of Meltdown and Spectre became public. This was important because Meltdown – which allows malware to extract passwords and other secrets from an Intel-powered computer's memory – is pretty easy to exploit, and cloud-computing environments were particularly exposed as they allow customers to share servers. Someone renting a virtual machine on a cloud box could snoop on another person using the same host server, via the Meltdown design gaffe.

Smaller cloud service providers were left playing "catch up." Joyent, a US cloud-services provider owned by Samsung Electronics, was among those that may have benefited from a warning but wasn't included in the select group informed ahead of the public reveal.

"Other folks had a six-month head start," Bryan Cantrill, the company's chief technology officer, told the WSJ. "We're scrambling."

"I don't understand why CERT would not be your first stop," Cantrill added.

El Reg asked Intel to comment on its disclosure policy. In a statement, Chipzilla told us it wasn't able to inform all those it had planned to pre-brief – including the US government – because news of the flaws broke before a scheduled 9 January announcement:

The Google Project Zero team and impacted vendors, including Intel, followed best practices of responsible and coordinated disclosure. Standard and well-established practice on initial disclosure is to work with industry participants to develop solutions and deploy fixes ahead of publication. In this case, news of the exploit was reported ahead of the industry coalition's intended public disclosure date at which point Intel immediately engaged the US government and others.

US CERT acts as a security clearing house. The agency initially advised that the Spectre flaw could only be addressed by swapping out for an unaffected processor before revising its position to advise that applying vendor-supplied patches offered sufficient mitigation.

El Reg asked US CERT for its take on how the disclosure process went down in the case of the Meltdown and Spectre vulnerabilities but we're yet to hear back. We'll update this story as and when more information comes to light."

Intel Warned Chinese Companies of Chip Flaws Before U.S. Government
Decision to disclose issue to select few customers, including Lenovo and Alibaba, has ripple effects through security and tech industries
By Robert McMillan in San Francisco and Liza Lin in Shanghai
Jan. 28, 2018 11:37 a.m. ET
https://www.wsj.com/articles/intel-...f-chip-flaws-before-u-s-government-1517157430

"In initial disclosures about critical security flaws discovered in its processors, Intel Corp. INTC -0.20% notified a small group of customers, including Chinese technology companies, but left out the U.S. government, according to people familiar with the matter and some of the companies involved.

The decision raises concerns, security researchers said, as it potentially could have allowed information about the chip flaws, dubbed Spectre and Meltdown, to fall into the hands of the Chinese government before being publicly divulged. There is no evidence any information was misused, the researchers said.

Weeks after word of the flaws first surfaced, Intel’s choices about who would receive advance warning continue to ripple through the security and tech industries.

The flaws were first identified in June by a member of Google’s Project Zero security team. Intel had planned to make the discovery public on Jan. 9—people working to protect systems from hacks often hold off on announcements while fixes are devised—but sped up its timetable when the news became widely known on Jan. 3, a day after U.K. website the Register wrote about the flaws.

Because the flaws can be leveraged to sneak sensitive data out of the cloud, information about them would be of great interest to any intelligence-gathering agency, said Jake Williams, president of the security company Rendition Infosec LLC and a former National Security Agency employee. In the past, Chinese state-linked hackers have exploited software vulnerabilities to get leverage on their targets or expand surveillance.

It is a “near certainty” Beijing was aware of the conversations between Intel and its Chinese tech partners, because authorities there routinely monitor all such communications, Mr. Williams said.

Representatives from China’s ministry in charge of information technology didn’t respond to requests for comment. The country’s foreign ministry has in the past said it is “resolutely opposed” to cyberhacking in any form.

An Intel spokesman declined to identify the companies it briefed before the scheduled Jan. 9 announcement. The company wasn’t able to tell everyone it had planned to, including the U.S. government, because the news was made public earlier than expected, he said.

Intel’s tricky path—inform enough big customers to head off significant damage while keeping the information as contained as possible to limit potential leaks—continues to weigh on smaller companies that weren’t given an early nod.

Joyent Inc., a U.S.-based cloud-services provider owned by Samsung Electronics Co. , is still playing catch-up, said Bryan Cantrill, the company’s chief technology officer.

“Other folks had a six-month head start,” he said. “We’re scrambling.”

In the months before the flaws were publicly disclosed, Intel worked on fixes with Alphabet Inc.’s Google unit as well as “key” computer makers and cloud-computing companies, Intel said in an emailed statement to The Wall Street Journal.

An official at the Department of Homeland Security said staffers learned of the chip flaws from the Jan. 3 news reports. The department is often informed of bug discoveries in advance of the public, and it acts as an authoritative source for information on how to address them.

“We certainly would have liked to have been notified of this,” the official said.

The NSA was similarly in the dark, according to Rob Joyce, the White House’s top cybersecurity official. In a message posted Jan. 13 to Twitter, he said the NSA “did not know about these flaws.” A White House spokesman declined to comment further, referring instead to the tweet.

Spoiler: Details...

Chinese computer maker Lenovo Group Ltd. LNVGY -1.22% was among the large tech companies, including Microsoft Corp. , Amazon.com Inc. and ARM Holdings in the U.K., that were notified of the flaws beforehand.

Lenovo was able to issue a statement Jan. 3 advising customers on the flaws because of “the work we’d done ahead of that date with industry processor and operating system partners,” a spokeswoman said in an email.

Alibaba Group Holding Ltd. BABA -1.08% , China’s top seller of cloud-computing services, also was notified ahead of time, according to a person familiar with the company.

A spokeswoman for Alibaba’s cloud unit declined to comment on when the company was informed. She said any idea that the company might have shared information with Chinese authorities was “speculative and baseless.”

A Lenovo spokeswoman said Intel’s information was protected by a nondisclosure agreement.

Despite the security concerns, an early heads up to a select number of large global companies made sense, said Dave Aitel, chief executive of Immunity Inc., a company that sells security services. “They’re going to tell as few people as possible” to contain possible leaks, he said.

Because they had early warning, Microsoft, Google and Amazon were able to release statements soon after news of the flaws leaked out saying their cloud-computing customers were largely protected.

Smaller competitors, though, continue to struggle. DigitalOcean Inc., a cloud-services seller, said Jan. 19 it was still testing a fix for its customers. Rackspace Inc. said last Wednesday it has several teams working on a fix. The cloud company earlier in January told customers it understood the situation “can be frustrating.”

The DHS also stumbled with its initial guidance. The agency’s Computer Emergency Response Team first linked to an advisory stating the only way to “fully remove” the flaws was by replacing the chip. CERT now advises users instead to patch their systems.

The DHS should have been looped in early on to help coordinate the flaws’ disclosure, Joyent’s Mr. Cantrill said. “I don’t understand why CERT would not be your first stop,” he said.

Write to Robert McMillan at [email protected] and Liza Lin at [email protected]

Appeared in the January 29, 2018, print edition as 'Intel Told China of Flaw Before U.S..'"

 

And who should trust on NSA ?

 

Why do they even need that simple exploits when they have their eyes on our devices and the internet from the start.

 

Even still, as unlikely/impossible as it seems, just imagine if this was the one time that they *didnt* know already. I mean i assume nsa prolly knew about this for years, and foreign agencies too. But what if they didnt? What if the one time nsa really wasnt omniscient, it happened to be the time that it realllllly mattered--when effectively every device in the world has glaring exploit--and chinese agency learned first from snooping on intel's alibaba/lenovo/etc headsup warning. Hardly feasible, i know, but stranger things have happened..

Like maybe intel assumed nsa already knew (either from independent prior discovery or their own snooping of internal memos) and didnt make official gesture to us gov't cuz they thought they already knew (and/or they didnt care).

But the irony would be delicious if for once everyone overestimated nsa and they really got caught with their pants down, meanwhile really good chance of chinese agencies learning first and having months to act...

I know, silly ....but still.. Just a kinda funny food for thought (or kinda scary possibility, or both)

 

No one, according to the NSA themselves. They just removed "honesty" and "trust" from the core values on their website. Though, why they were there in the first place is beyond me. Seems like honesty might be something that could be exploited against them.

 

Because if they are exposed, then someone can steal all the data they have on everyone else! Talk about giving away the farm!

 

Here is the truth. The governments don't care about securing their citizens data (except certain corporations and individuals and intellectuals/acedemics). What they care about is information! What do other countries know that they do not, what do they know that others do not, etc. An exploit like this can cause a major imbalance on that front. Now, disregard whether you agree with their endgame (or can even divine it). It can expose human agents in the field, which they do want to protect those assets. Those assets are also used in negotiated bargains in this game they play. Or, those assets, now known, can be left in play and fed bad intelligence, thereby weakening the information dynamic that is so delicate as is. As such, that is what they are worried about under the guise of national security, because they are still playing old games in new times.

The question is when they will stop the us versus them dynamic and are ready to move forward. Unfortunately, each major player believes they must have full control over the narrative and policies moving forward when we get to that point, as globalization will occur. They also have certain fears on what retaliations may be had and what rights will prevail, although we have too many moving on fears based out of a different time (like returning to cold war rhetoric or trying to threaten China with economic policy, which caused a different issue of China now being better positioned to weather a financial crisis globally than the US with a potential to emerge as the new hard currency due to our idiocy in econ policy). But, I digress.

It is only scary if you let it scare you. They cannot get our nukes. They could get troop movements, which is scary because those servicemen and women do not deserve harm. It could weaken positions in negotiations with North Korea, but N.K. offered to dismantle the program if we came to the table with no pre-conditions last spring. Had we done that, they never would have achieved the hydrogen bomb they tested nor the creation of an ICBM able to reach the continental US. So, in reality, we caused our own problems in that fight.

If the NSA didn't know this, yet knew enough to force certain aspects of the Management Engine be altered for security reasons, with those being shown as an exploit to the public only many years later, I'd wonder how the **** they dropped the ball. If they didn't know, they are currently having fun with a complete scrub down of agency systems. If you don't see that happening, then they knew. Period.

 

Where am I? What do you want! Who's side are you on!!




[ All serious and good points... But every time I hear about using or wanting 'information'... Sorry, I just can't resist. ]

 

I would think they wouldn't want whether they knew to be public, I'd keep it quiet if I had to do that.

 

Most won't know because wipe downs like this are not made public. Unless you know a guy on the inside telling you about the headache going on, no one will ever know, except for the foreign intelligence agency that loses access due to the wipe.

 

They have to have all kinds of black funding. If they know they're being exploited it might be interesting if they were to quietly build up something new in parallel and use the existing system to leak misinformation while it's being dismantled.

 

That exact thought had crossed my mind as well. Great for giving disinformation. But, the information after public is all viewed with a scrutinizing eye, as you don't know veracity. Seems like a fun game if not for being real life.

 

True. I figure it would only work until whatever foreign agency is viewing it tries to act on some of it.

 

It's ‘disturbing’ that Intel may have told China about chip flaws before US, says Congressman
Kellie Ell | @KellieAutumnEll Published 22 Hours Ago
https://www.cnbc.com/2018/01/29/rep...el-told-china-about-chip-flaws-before-us.html

Intel may have informed Chinese companies about 'Meltdown' and 'Spectre' security flaws before telling the U.S. government, according to a Wall Street Journal report.

GOP Congressman Gregory Walden calls the claims 'disturbing.'

Many Chinese companies have direct ties to the Chinese government, Walden says.

Walden, who is also a chair on the House, Energy and Commerce Committee, says the Committee is asking top companies what they knew.

"Claims that some Chinese companies may have had knowledge about security flaws in Intel chips before the U.S. government is "troublesome," said Republican Congressman Gregory Walden.

Walden's statement came a day after The Wall Street Journal reported Intel informed Chinese companies about the 'Meltdown' and 'Spectre' security flaws before it told the U.S. government.

"If true, I think The Wall Street Journal reporting is very disturbing about what may have happened," Walden told CNBC on " Squawk Alley" Monday morning.

The flaws, which made sensitive information — such as passwords — vulnerable to hacking on computers, mobile devices and cloud networks around the globe, were found earlier this year. Tech experts said the bugs, named Spectre and Meltdown, were design flaws.

Many Chinese companies have direct ties to the Chinese government, Walden said, which means the Chinese government may have known about the security vulnerabilities before the U.S. government or American companies — companies that may have been exposed to the security flaws.

"If they did [know] it's very troublesome," Waldon said.

"You wonder, of all the sectors that are out there, from energy to health care, who were kept in the dark about this," he said. "When you tell [Chinese companies] you're running a risk, an obvious one, that you're telling the Chinese government."

"If a foreign government knew, did they do something? Or could they have exploited this?" he said.

Walden, who is also a chairman on the House, Energy and Commerce Committee, said Congress has asked top execs at Apple, Amazon, AMD, Google, Arm, Intel and Microsoft how long they knew about the flaws and why they choose to keep them a secret.

Congress is just starting to hear back from some of the companies but has no definite answers yet, Walden said."

 

He sums it all up nicely

Is Intel Going Downhill & Are Their Glory Days Over?

 

I do not see AMD fully closing the gap till 2019 or later. 12nm will help somewhat but Zen+ is sorely needed.

 

But they go strong with Graphics Performance in their Processors Not what I look after in a Cpu.

 

It’s Happening – Attackers Start Testing Malware Exploiting Spectre and Meltdown Flaws
"The details of the Spectre and Meltdown bugs have been out in the public for a few weeks now and barely any devices are patched up against these security disasters. Security researchers now report having discovered over 130 malware samples trying to specifically exploit these recently discovered and patched vulnerabilities. Mostly in the testing phase, successful attacks in the wild are expected to begin soon."

Researchers at AV-Test also reported seeing 119 new samples focused on these vulnerabilities between January 7 and January 22. In the past week, that number reached to 139. “Most appear to be recompiled/extended versions of the PoCs – interestingly, for various platforms like Windows, Linux and MacOS,” Andreas Marx, CEO of AV-Test, told SecurityWeek. “We also found the first JavaScript PoC codes for web browsers like IE, Chrome or Firefox in our database now.”

While software companies and chip makers are scrambling to release updates that don’t breaksystems, Marx also advises users to switch off computers and close web browsers when not needed, which “should decrease your attack surface a lot.”

 

Let's just send an emp which will remove the problem lol. Seriously though as alot of gaming needs Internet connection at all times due to drm and games saves what are we supposed to do? Even our routers are vulnerable now as manufacturers don't allow firmwares for older devices even 1 year old. I have VPN but even that's compromised by the spectre and meltdown grrr I really think we're all screwed. Is it really time to go offline? It wouldn't surprise me if drm could be to blame.

Sent from my SM-G920F using Tapatalk

 

Myths About Meltdown & Spectre: Expert Interviews


Joel Doxtator 2 days ago
"I use my PC for HiFi audio and the new update absolutely destroys the quality of my bit-stream to my DAC. There is so much digital jitter now that everything sounds muffled. Ripping out my old windows CD, reinstalling and disabling windows update. BRB...."

Joel Doxtator 2 days ago
"This is a god damned mess... Apparently, windows released an emergency update trying to fix what Intel did wrong and that is what killed my audio stream. Windows 10 lite here I come."

Joel Doxtator 2 days ago
"All fixed, back to an older version of windows 10 and disable windows updates. Hugely frustrating. Will be running old windows until this all blows over."

Walther Penne 2 days ago
"Spectre-patch eats cpu-bandwidth.Audio needs lots of bandwidth. Lesser bandwidth means worse audio-quality!"

Joel Doxtator 2 days ago
"If this is the way they are patching it until there is a hardware fix, old windows versions with updates blocked are going to become extremely popular."

 

Hundreds Of Meltdown, Spectre Malware Samples Found In The Wild-Tomshardware.com

Most Devices Will Likely Remain Exposed
Intel has promised some Meltdown and Spectre fixes only for chips released in the past five years, and it has promised to look at patching older chips later on, too. However, Intel has already pulled its Spectre variant 2 patch because it was causing rebooting errors for some Intel-based computer owners, so everyone will remain vulnerable to this flaw for the time being.

Additionally, the microcode updates that Intel is releasing have to be integrated and delivered by device makers. In other words, we’re all at the mercy of OEMs who may not release patches for all but the newest devices. Most of the currently used PCs, notebooks, and mobile devices may never see microcode fixes.

 

The GN vid seems to confirm some of my suspicions about the actual likelihood of end user exposure and the impact on their systems, which makes me feel slightly better about the whole thing. But only slightly.

 

One more reason to go with business-class machines, tbh - most of reasonably recent ones got either the update, or at least a promise of it.

On side note, two BSOD episodes I reported earlier after applying BIOS update addressing Spectre may have been caused by WLAN driver instead, judging by its changelog.

 

If you have never had any problem with W-LAN driver before and card was long-time used in laptop then it could be BIOS update.

 

Torvalds Releases Linux 4.15 With Improved Meltdown, Spectre Patches
By: Sean Michael Kerner | January 29, 2018
http://www.eweek.com/enterprise-app...x-4.15-with-improved-meltdown-spectre-patches

"Linus Torvalds released the first new Linux kernel of 2018 on Jan. 28, after the longest development cycle for a new Linux kernel in seven years.

During the release Linux Kernel release cycle, Torvalds typically issues a release candidate once a week, with most cycles including six to eight release candidates.

There were nine release candidates for the Linux 4.15 kernel, which makes it the longest cycle since Linux 3.1 was released in 2011. The Linux 3.1 kernel was delayed in part due to the 2011 hack of the kernel.org development server.

As it turns out, the Linux 4.15 kernel release delay was also due to security related issues.

Spoiler: Details...

Among the highlights of the new Linux 4.15 kernel is the core reason for the kernel's delay, namely the Meltdown and Spectre CPU flaws, that first became public on Jan. 3. Linux developers had been quietly working since at least November 2017 on dealing with the Meltdown issue in particular through an effort known as Page Table Isolation (PTI).

"This obviously was not a pleasant release cycle, with the whole meltdown/spectre thing coming in in the middle of the cycle and not really gelling with our normal release cycle," Torvalds wrote in his release announcement. "The extra two weeks were obviously mainly due to that whole timing issue."

The Meltdown flaw, identified as CVE-2017-5754, affects Intel CPUs while Spectre, known as CVE-2017-5753 and CVE-2017-5715, impacts all modern processors. The issues also impact Microsoft Windows, which has had multiple stability issues related to the patch. On Jan. 28, Microsoft issued an emergency out-of-band Windows update that disables the patch for the CVE-2017-5715 (Spectre) issue due to stability issues that were triggering data loss and system reboots.

The Spectre issue is being mitigated in Linux 4.15 with the retpoline code that was originally developed by Google. Reptoline helps to avoid kernel-to-user data leaks, by restricting speculative indirect branches in CPU processes.

Torvalds also noted that there is still more work to be done to further protect users against the Meltdown and Spectre vulnerabilities. That said, he emphasized that Linux 4.15 is about more than just patches for CPU vulnerabilities.

"While Spectre/Meltdown has obviously been the big news this release cycle, it's worth noting that we obviously had all the *normal* updates going on too,"Torvalds wrote. "The work everywhere else didn't just magically stop, even if some developers have been distracted by CPU issues."

Among the new features that have landed in Linux 4.15 are a set of capabilities to support expanded security capabilities in Intel and AMD CPUs. On AMD, Linux now supports the AMD Secure Encrypted Virtualization (SEV) capability.

"SEV enables running encrypted virtual machines (VMs) in which the code and data of the guest VM are secured so that a decrypted version is available only within the VM itself," the code commit for the feature states.

On Intel CPUs, Linux now supports a feature called User Mode Instruction Prevention (UMIP) that is intended to help limit the risk of privilege escalation. Ricardo Neri, Linux software engineer at Intel explained in his Linux kernel commit message that UMIP is a security feature present in new Intel Processors.

"If enabled, it prevents the execution of certain instructions if the Current Privilege Level (CPL) is greater than 0," Neri wrote. "If these instructions were executed while in CPL > 0, user space applications could have access to system-wide settings such as the global and local descriptor tables, the segment selectors to the current task state and the local descriptor table. Hiding these system resources reduces the tools available to craft privilege escalation attacks."

 

Of course. However, originally I stated that it is definitely the Spectre BIOS update causing BSODs; with the new information about WLAN driver (which I update routinely, without paying much attention except for reading changelogs), it turns out Spectre BIOS update may or may not have caused the BSODs.

Regardless, I thankfully didn't have any more BSODs afterwards; the machine typically runs without pagefile, so there were no dumps to analyze, and we won't know for sure what caused BSODs unless they happen again - and I very much hope they won't!

 

Insecure by design – lessons from the Meltdown and Spectre debacle
Gernot Heiser Yuval Yarom February 4, 2018 1.05pm ES
http://theconversation.com/insecure-by-design-lessons-from-the-meltdown-and-spectre-debacle-90629

"The disclosure of the Meltdown and Spectre computer vulnerabilities on January 2, 2018 was in many ways unprecedented. It shocked – and scared – even the experts.

The vulnerabilities bypass traditional security measures in the computer and affect billions of devices, from mobile phones to massive cloud servers.

We have, unfortunately, grown used to attacks on computer systems that exploit the inevitable flaws resulting from vast conceptual complexity. Our computer systems are the most complex artefacts humans have ever built, and the growth of complexity has far outstripped our ability to manage it.

Spoiler: A new kind of vulnerability

A new kind of vulnerability
Meltdown and Spectre are qualitatively different from previous computer vulnerabilities. Not only are they effective across a wide class of computer hardware and operating systems from competing vendors. And not only were the vulnerabilities hiding in plain sight for more than a decade. The really shocking realisation is that Meltdown and Spectre do not exploit flaws in the computer hardware or software.

As Intel stated in its press release, these attacks:

…gather sensitive data from computing devices that are operating as designed.

The ingenuity of the attacks lies in combining seemingly unrelated design features that were thought to be well understood – stuff we teach undergraduate computer science students. The vulnerability is not in any of the individual features, but in the complex interaction between them.

It turns out that computer systems are insecure not because of mistakes made in the implementation, but because of ill-conceived design.

As a community of computer systems experts, we have to ask ourselves how such a debacle is possible, and how a recurrence can be prevented.

We have known for a while that the established “wait for something to happen and then try to fix it” approach – better known as “patch and pray” – does not work even for more common implementation flaws, as witnessed by the proliferation of exploits. It works even less well for such insecure-by-design situations.

Automated evaluation of designs
The fundamental problem is that humans are unable to fully understand the conceptual complexity of modern computer systems and how its seemingly unrelated features might interact. There is no hope that this will change.

But solving complex problems is what machines are increasingly good at. So, the only real solution can be the automated evaluation of designs, with the aim of mathematically provingthat under all circumstances a design will behave in a way that is considered secure – in particular by not leaking secret data.

In other words, a design must be considered insecure unless there is a rigorous mathematical proof to the contrary.

This is not an easy ask by any definition, and much more work across many areas of computer science and engineering is needed to make it a reality. But we need to start somewhere, and we need to start now.

We will reap benefits of embarking on such a program long before we achieve the goal of rigorous end-to-end proof. Significant improvements will be achieved through partial results, both in the form of proving weaker properties, and by establishing desired properties in a less rigorous fashion.

For example, an incomplete evaluation may be more feasible than a complete one, and produce a probabilistic result, such as a greatly reduced likelihood of exploits.

Rewriting the hardware-software contract
A necessary, and overdue, first step is a new and improved hardware-software contract.

Computer systems are a combination of hardware and software. The people and companies that develop hardware are largely separate from those developing the software. Given the vastly different skills and experience required, this is inevitable.

To make development practical, both sides work to an interface, called the instruction-set architecture (ISA), which presents the contract between hardware and software functionality.

The problem, clearly exhibited by the Meltdown and Spectre attacks, is that the ISA is under-specified for security, or safety for that matter. It simply does not provide ways to isolate the speed of progress of a computation from other system activities.

The ISA a functional specification, meaning it defines how the visible state of the machine will (eventually) change if an operation is triggered. It intentionally abstracts away anything to do with time. In particular, it hides how long operations take and how this time depends on the internal state of the machine. The problem is that this internal state depends on potentially confidential data processed by previous operations.

This means that by observing the exact timing of particular sequences of operations, it is possible to infer data that is supposed to be kept secret. This is exactly what happened with Meltdown and Spectre.

The abstraction is there for a good reason: It allows hardware designers to change things “under the hood”, usually in order to improve performance. Consequently, there will be resistance from hardware manufacturers to a tighter contract. But we believe that the refined specifications can be kept abstract enough to retain manufacturers’ ability to innovate, and to avoid exposing confidential IP.

The recent debacle has shown that the ISA is too abstract, making it impossible to tell whether a system is secure or if it will leak secrets. This must change, urgently."

Chipmakers Discuss a Future After Meltdown and Spectre
Engineers from Intel, AMD, and ARM discuss what lies ahead for engineers, and the chip industry in general, in the wake of the Meltdown and Spectre hardware bugs.
by: Chris Wiltz DesignCon - Santa Clara Consumer Electronics, Cyber Security, Government/Defense, Electronics & TestFebruary 05, 2018
https://www.designnews.com/content/...ure-after-meltdown-and-spectre/42684598058203

"At a recent panel at DesignCon 2018, “Continued Innovation in a World Challenged by the Slowing of Moore's Law,” a group of engineers from Intel, AMD, and ARM weighed in on the impact of Meltdown and Spectre chip hardware bugs and how they could impact the chip industry going forward.

Spoiler: Details...

Chipmakers did not begin 2018 on a high note. In early January, reports came flooding in of a pair of hardware vulnerabilities affecting CPUs going back as far as 20 years. The bugs, Meltdown and Spectre, were initially discovered by researchers at Google in June 2017, but information about them leaked to the public before a major fix for either could be implemented. This created a scramble not only by major chipmakers Intel, ARM, and AMD but also among big technology names like Apple, Microsoft, and Google to quickly fix the problems before they could become the latest tricks in malicious hackers' toolboxes. A repository has sprung up on Github that features several applications that demonstrate the Meltdown bug. Twitter user, Michael Schwarz, who holds a PhD in information security, demonstrated how easy it would be to steal passwords by exploiting Meltdown in short enough time to fill an animated gif.

Using #Meltdown to steal passwords in real time #intelbug #kaiser #kpti /cc @mlqxyz @lavados @StefanMangard @yuvalyarom https://t.co/gX4CxfL1Ax pic.twitter.com/JbEvQSQraP

— Michael Schwarz (@misc0110) January 4, 2018

What made these particular exploits so thorny is that rather than typical software issues, these were hardware bugs built right into the design of the chips themselves. According to an i nformation site hosted by Graz University of Technology in Austria, Meltdown gets its name because it “basically melts security boundaries which are normally enforced by the hardware” and Spectre, though harder to exploit than Meltdown, gets its name because it is not an easy bug to fix and “it will haunt us for quite some time.”

“When I started designing CPUs in the mid '80s we did speculative execution,” Joe Macri, Corporate Vice President, Product Chief Technology Officer, and Corporate Fellow at AMD, told a DesignCon audience. “Speculative execution isn't going to stop; it's how we move fast. What has to change is our understanding and appreciation of the need for secure systems and end-to-end security.”

Another panelist Rob Aitken, a Fellow and Director of Technology at ARM, emphasized that its going to take industry collaboration across all chipmakers to ensure that bugs like these don't emerge in the future. Aitken said that, going forward, engineers will need to think more about designing for resilience against cyberattacks. “Security is and has always been a feature that needs to be included in any design,” he said.

“The industry knows how to collaborate when it's in our best interest,” Rory McInerney, VP of the Platform Engineering Group and Director of the Server Development Group at Intel, added. “This is an exposure that was caught before it was knowingly exploited, so you have to commend the industry on moving quickly on that.”

McInerney also believed more will need to be done on the education and training level for chip designers and engineers as well to assist with testing for cyberattacks. “I think there will be a lot more investment in a lot of the tools and methods of how we attack a design from a security perspective,” he said. “We nee more tools that allow you to do these attacks at a basic building block level in order to make designs more robust. There needs to be more done to make security assurance more mainstream.”

To McInerney's point that Meltdown and Spectre haven't been exploited yet, reports are already emerging of malware being created based off of the bugs. With chipmakers still rolling out fixes for machines affected by the bugs, it may only be a matter of time before we see the first major Meltdown or Spectre hack. On February 1, AV-Test GmbH, a German IT security firm, reported that it had found 139 examples of malware that looked to be attempts to take advantage of Meltdown or Spectre.

Though patches have been released for operating systems, chips, and web browsers, with 20 years worth of vulnerable machines out there it seems highly unlikely that every system will ever be fully patched. And it doesn't mean there aren't other, similar chip hardware issues out there waiting to be discovered and possibly exploited.

“What's changed with Spectre and Meltdown is it's a different form of side-channel attack than people were expecting perhaps,” ARM's Aitken said. “But the nature of side-channel attacks is essentially that they're not what you would expect. We can predict without having to use a crystal ball that there will be future side channels. ...The reality is you can't avoid them, they're going be there; they're going to disrupt things that we thought were less vulnerable than they actually turned out to be.”

Aitken said Meltdown and Spectre in particular should get engineers thinking more about the implications of side-channel attacks – attacks based on computing hardware rather than software – when they are designing chip architecture. “What sorts of things have to change in people's mind when they think about architecture that encompasses side channels?” Aitken asked. “Beyond that, there's the question of what are the metrics. It's ridiculous to say one thing is secure and another is not. It's like if you go look at your own house or your car. Is it secure? That depends. It's not really so much is it secure as it is how much effort does it take to break into it, because somebody somewhere can.”

“We all live in glass houses in this industry and we're all in it together,” AMD's Macri said. “It's not three companies or four companies. It's all companies... It's something that we live with everyday and we're striving to do a perfect job in a world that isn't perfect. We'll just keep at it.”

Aitken said, “We not only have to design systems that are secure against the expected challenges of the moment, we have to actually design them so that they're resilient against some kind of attack in the future that we can't predict right this minute, but we know is coming.”

Moving to conclude the discussion on an optimistic note, moderator Bob O'Donnell, President, Founder and Chief Analyst at TECHnalysis Research, offered, “The silver lining is it drives more corporation. In theory this provides a way for companies to know how to work together to solve this.”

Jon Masters On Understanding Spectre & Meltdown CPU Vulnerabilities
Written by Michael Larabel in Linux Events on 5 February 2018 at 07:38 AM EST.
https://www.phoronix.com/scan.php?page=news_item&px=Jon-Masters-Spectre-Meltdown

"Arguably the most interesting keynote at this year's FOSDEM event was Red Hat's Jon Masters talking about the Spectre and Meltdown CPU vulnerabilities on an interesting technical level.

While Jon Masters is mostly known for his involvement with Fedora/RedHat on ARM hardware, he was the lead for Red Hat's mitigation efforts around the Meltdown and Spectre vulnerabilities that rocked the world last month.

Jon's keynote presentation covered the microarchitecture of modern CPUs, helped listeners understand CPU caches / virtual memory / branch prediction / speculative execution, and finally went on to talk about the Spectre and Meltdown vulnerabilities with the current approaches and solutions for mitigating these high impact issues.

If you are interested in learning more, there is a WebM video recording of his presentation as well as the PDF slide deck."

 

I'm no expert but this has been my feeling for a couple years. Everything is so chaotic now. The rate of major security issues seems to be growing (in the last year we had WannaCry ransomware, wifi KRACK vulnerability, Equifax data breach, and Meltdown/Spectre to name a few). Windows Update is a mess. Some Android phone manufacturers slack off considerably with security updates. The fragmentation within and across platforms is staggering.

It's like the Second Law of Thermodynamics. Entropy (disorder, randomness) keeps increasing. We have things like self-driving cars and smart home devices (internet of things seems like a security/privacy nightmare). AI and machine learning are going to be huge this year. Cryptocurrency and blockchain are the current big thing, and cryptominers are the new malware. Mobile technology continues to grow rapidly with every generation of phones trying to make the last one look outdated.

We can do all these amazing things but cybersecurity and maintenance seem like afterthoughts because the next big technology or gadget is always around the corner. Maybe we should all just accept our fates as data points to be harvested by an endless wave of technology.

 

There was a bios updated posted within the last few days for my motherboard. It doesnt say anything about a patch for any vulnerabilities, but does have the new agesa code. I would love to update, but am concerned their is a patch buried in it. This is what it says, and the release date shows as the 29th of January.

- Improved memory compatibility.
- Improved PCIE device compatibility.
- Update AGESA Code 1.1.0.1 to support Raven Ridge CPU.

 

You will see a drop of 1% in worst case scenario. If you want to experiment you can try the uCode pack I sent you, you can have similar effects of BIOS update to judge its performance. If its bad you can uninstall it unlike a BIOS update.

 

I'd check first to see if the BIOS "update" software will allow downgrading.

By default the CLI command won't do this, it requires a newer date BIOS to overwrite the current. But there is an option to override this limit, for example with winflash:

winflash /nodate

Then you'd be safe trying a new BIOS knowing you can downgrade if it doesn't work out.

Don't forget to write down all of your BIOS changes in case they get reset, I'd go so far as to take clear photo of each BIOS screen you make changes to, so you can see the difference if there are new options or tabs available after update.

Also, I use whatever the option is to "load optimized defaults" first thing after resetting after flashing a new BIOS, I go into the BIOS first to do that before booting into Windows - I also then save the optimized defaults, which resets again, and this time I go into the BIOS and set my changes, save again, reset and restart again, and this time I let it boot into Windows.

Sometimes the alignment of settings changes, and loading optimized defaults after flashing the new BIOS lets it clean up and install it's defaults, starting with a clean slate.

I don't think the MB vendor is going to slip in the Spectre/Meltdown BIOS changes without noting that.

Besides Intel told everyone to stop using them, so that's likely the state of the relationship until Intel gives a go signal again.

What does your vendor / AMD have to say?

 

Well its AMD Ryzen and not Intel.

 

Yeah, I know that, but I don't think AMD is going to push a BIOS change that the vendor won't disclose either.

I had the detailed info on the Intel status to give an example, but not on AMD, I figured you'd know the difference.

How about you post what the steps are to flash an older BIOS over a newer BIOS for your motherboard, and what AMD has issued for BIOS update for Vulnerabilities, that would be helpful.

AMD Processor Security
http://www.amd.com/en/corporate/speculative-execution

 

I don't have a desktop board anymore. Usually EZ Flash or QFlash or similar can rollback/upgrade BIOS even with protection.

 

@Raiderman

What Ryzen AMD motherboard do you have then?

It looks like AMD is just now getting out BIOS updates, so it's probably too soon to expect them to be rolled out in recent BIOS updates.

I don't think your motherboard vendor is going to push a BIOS change with a Vulnerability fix without disclosing it in the change list.

Usually the vendor likes to test them for a few weeks in the lab and field before releasing them, even if they are for emergency - general release would be a while longer than immediately. It is likely this update was in the works well before AMD started contacting vendors with the Vulnerability microcode updates.

AMD Processor Security
http://www.amd.com/en/corporate/speculative-execution

An Update on AMD Processor Security - 1/11/2018

"GPZ Variant 2 (Branch Target Injection or Spectre) is applicable to AMD processors.

• While we believe that AMD’s processor architectures make it difficult to exploit Variant 2, we continue to work closely with the industry on this threat. We have defined additional steps through a combination of processor microcode updates and OS patches that we will make available to AMD customers and partners to further mitigate the threat.
• AMD will make optional microcode updates available to our customers and partners for Ryzen and EPYC processors starting this week. We expect to make updates available for our previous generation products over the coming weeks. These software updates will be provided by system providers and OS vendors; please check with your supplier for the latest information on the available option for your configuration and requirements."

Like AMD says, check with your supplier, I'd send them an email with your posted details and question, they are most able to answer for certain what's in their BIOS update.

 

Intel adopts Orwellian irony with call for fast Meltdown-Spectre action after slow patch delivery
For now, have some code that won't crash Skylakes and stay close to your Telescreens
By Simon Sharwood, APAC Editor 8 Feb 2018 at 08:03
https://www.theregister.co.uk/2018/02/08/intel_spectre_meltdown_microcode_update/

"Intel's offered the world some helpful advice about how to handle the Meltdown and Spectre chip design flaws it foisted on the world.

"I can't emphasize enough how critical it is for everyone to always keep their systems up-to-date," wrote Navin Shenoy, executive veep and general manager of Intel's data centre group, bemoaning the fact that punters are slow to install patches and criminals use that tardiness to do their worst.

Sound advice, but a bit hard to swallow given that Shenov's "Security Issue Update" revealed that Intel is yet to develop properly working microcode updates for many of the CPUs imperilled by Spectre and Meltdown.

The effort to do so turned out to be more complicated than Intel thought, as some of its early updates made the silicon unstable. So unstable, in fact, that Intel recommended rollback as the best option.

Chipzilla has managed to sort out sixth-generation Skylakes, as a February 7th Microcode Revision Guidance (PDF) document records.

But Shenov's post - the first on Meltdown/Spectre to grace Intel's newsroom since January 22nd - also explained that the company "expects" to have working microcode or other platforms in coming days. Just what will land or when is anyone's guess.

The post also points out that PC-and-server-makers, not Intel, will be the source of the fixes.

There's more irony in Shenov's signoff, which says "We remain as committed as ever to addressing these issues and providing transparent and timely information."

Given that Intel approved the formation of a small cabal of OEMs to address the problem and kept their efforts secret for months, then dodged questions from the press and has now been asked to explain itself by the US congress, we hope Shenov is talking about some form of transparency other than Intel's previous action as this crisis unfolded. "

 

Intel re-issues Meltdown and Spectre patches with fresh code to rid users of performance issues
Lee Bell, 8 Feb, 2018
http:// www.itpro.co.uk/security/30485/intel-re-issues-meltdown-and-spectre-patches-with-fresh-code-to-rid-users-of

"After issuing a patch to fix the Spectre and Meltdown flaws in its Skylake chips, then telling users not to download it after all because it was causing performance issues, Intel has finally issued a working update.

It arrives over two weeks after original buggy patch release, where the chip giant quickly decided to advise customers not to download it, and Microsoft issued an update to reverse it.

At the time, the firm’s executive vice president, Navin Shenoy, apologised for the issues being caused and recommended OEMs, cloud service providers, system manufacturers, software vendors, and end users “stop deployment of current versions on specific platform as they may introduce higher than expected reboots and other unpredictable system behaviour”.

However, Intel has said that a working update free of any nasty side effects is now shipping to its PC partners with a fresh code that doesn’t cause system instability. Although the new patch addresses just a subset of the affected users, focusing on those who own Skylake-based Core or Core M processors.

While Intel said late last month it was testing a fix for Haswell and Broadwell PCs, it's still yet to roll this out. But an Intel blog post revealed patches should be hitting "more platforms in the coming days.”

The new patch has been a long time coming for some, and might be too little too late. Especially Linux creator Linus Torvalds, who lambasted Intel for the fiasco surrounding its patching process, calling the fixes "pure garbage".

In a post on the Linux kernel mailing list, Torvalds said the patches “do literally insane things” to the performance of the systems they are installed on.

“They do things that do not make sense,” Torvalds said. “That makes all your arguments questionable and suspicious. The patches do things that are not sane. WHAT THE F*CK IS GOING ON?”

He continued to rant that the patches are “ignoring the much worse issue, namely that the whole hardware interface is literally mis-designed by morons”."

Intel releases stable Spectre patches for Skylake PCs, recovering from a bad bout of bugs
No word yet on when Broadwell and Haswell systems will get updated code.
By Mark Hachman Senior Editor, PCWorld | FEB 7, 2018 4:54 PM PT
https://www.pcworld.com/article/325...s-stable-spectre-patches-for-skylake-pcs.html

"If you own a Skylake-based PC and receive a patch to address the Spectre vulnerabilities, install it—Intel has greenlit the code.

About two weeks after Intel recommended users halt or roll back Spectre and Meltdown patches because of system instability, the company disclosed that it has shipped new code to its PC partners that solves the problems of the earlier, buggy patch.

Right now, though, the new patches address just a subset of the affected users: specifically those who own Skylake-based Core or Core m processors. On January 22, Intel said it had begun testing a fix for Haswell and Broadwell PCs, though Intel has not rolled that final patch code to its partners. An Intel spokesman didn’t immediately respond to an emailed question about when those patches would be available, though an Intel blog post said it would patch "more platforms in the coming days."

“Earlier this week, we released production microcode updates for several Skylake-based platforms to our OEM customers and industry partners, and we expect to do the same for more platforms in the coming days,” Navin Shenoy, executive vice president and general manager of the Data Center Group at Intel, wrote in the blog post. “We also continue to release beta microcode updates so that customers and partners have the opportunity to conduct extensive testing before we move them into production.”

Intel said that the code has been approved for the Skylake U-, Y-, H-, and S-series chips, as well as the U23e. Intel’s updates come as part of a new document that tracks the progress of the microcode revisions, which will presumably continue to be updated over time.

In early January, Intel disclosed that virtually all of its microprocessors were potentially affected by both the Spectre and Meltdown vulnerabilities, which attack the speculative architecture of Intel’s chips. Other manufacturers were also affected, including ARM and to a lesser extent, AMD. But while Intel works to eliminate the Spectre and Meltdown vulnerabilities from future designs (and AMD does as well), the industry has had to deal with the issue that the patches themselves will slow down their PCs. Check PCWorld's constantly updated Spectre FAQ to keep up with all the latest developments.

What you need to do: Patch. In this case, Intel’s Shenoy himself puts it best: “Ultimately, these updates will be made available in most cases through OEM firmware updates,” he wrote. “I can’t emphasize enough how critical it is for everyone to always keep their systems up-to-date. Research tells us there is frequently a substantial lag between when people receive updates and when they actually implement them. In today’s environment, that must change.”"

 

For skylake, I see the same uCode C2.

 

It's an MSI X370 gaming pro carbon. I think I have the ability to roll back the bios through ezflash. It looks like AMD is making the patch an optional flash, via your link. So I will update this weekend, and see how it performs. Back in the day, they used to roll out monthly bios updates, not 5 months. The last bios update is dated September.

Sent from my SM-G935T using Tapatalk

 

Intel releases new Spectre microcode update for Skylake; other chips remain in beta
Previous microcode update was reported to cause unwanted system reboots.
Peter Bright - 2/7/2018, 5:25 PM
https://arstechnica.com/gadgets/201...kylake-other-chips-remain-in-beta/?comments=1

"After recommending customers not use its microcode fix for Broadwell and Haswell chips, Intel has issued a new microcode update for Skylake processors that gives operating systems the ability to protect against the Spectre flaw revealed earlier this year.

The Spectre attacks work by persuading a processor's branch predictor to make a specific bad prediction. This bad prediction can then be used to infer the value of data stored in memory, which, in turn, gives an attacker information that they shouldn't otherwise have.

The microcode update is designed to give operating systems greater control over the branch predictor, enabling them to prevent one process from influencing the predictions made in another process.

Intel's first microcode update, developed late last year, was included in system firmware updates for machines with Broadwell, Haswell, Skylake, Kaby Lake, and Coffee Lake processors.

But users subsequently discovered that the update was causing systems to crash and reboot. Initially, only Broadwell and Haswell systems were confirmed to be affected, but further examination determined that Skylake, Kaby Lake, and Coffee Lake systems were rebooting, too.

In response, consumers were advised not to use the new microcode, and operating system features that leveraged the new capabilities were disabled.

The new microcode is being distributed to hardware companies so that they can include it in a new range of firmware updates. This latest update is only for mobile Skylake and mainstream desktop Skylake chips.

It neither fixes the Broadwell or Haswell problems, nor does it apply to Kaby Lake, Skylake X, Skylake SP, or Coffee Lake processors.

Intel says that beta testing of other microcodes for these processors is ongoing. As such, laptop and desktop owners of Skylake systems should see firmware updates arriving soon. Everyone else, however, still has to wait."

Spoiler: Comments...

Sasparilla Ars Scholae Palatinae et Subscriptor FEB 7, 2018 5:36 PM

It's Intel, they know what they're doing. /s

Who wants to go first?

hollis Smack-Fu Master, in training FEB 7, 2018 5:51 PM

I highly doubt mainboard manufacturers will make new bios/uefi firmwares now just for Skylake and then again do new ones when Kaby etc. is done (given that Skylake and Kaby Lake run on the same boards). At best they'll do one new firmware for such boards, once all new microcode updates are out. Everything else would really surprise me.

NinjaNerd56 Ars Tribunus Militum FEB 7, 2018 6:03 PM

Just installed...

...luks lik iswrkng finn.

Fatesrider Ars Tribunus Militum et Subscriptor FEB 7, 2018 6:11 PM

Given that this is for Skylakes and I have a Haswell, I'll pass, thanks.

I'm going with AMD next time I upgrade. Intel's response to this problem makes me wonder what ELSE it knows about, but isn't revealing. I can't for the life of me imagine why the problem wasn't shared in the same manner as other security flaws have been in the past - unless there's more to hide there than this (at least off the top of my cynical head).

I expect by the time I go out and do that, AMD will have fixed the problem with Spectre. I'm a bit less confident that Intel won't be patching theirs for a while.

In the meantime, I expect we'll be serenaded by the distant screams of frustration as computers periodically reboot themselves for no apparent reason for some time to come...

KMorgan Smack-Fu Master, in training FEB 7, 2018 6:42 PM

Just a point, the biggest concern I've seen among users has been corruption, especially in data work loads: Three days later Intel acknowledged in its quarterly earnings report that the glitchy firmware can also cause “data loss or corruption.” This disclosure prompted Microsoft to take the unusual step of releasing an emergency Windows update designed to disable Intel's fix for one of the two Spectre variants.

 

Wow, what a mess. I thought they would be able to lock that down with the next update, looks like it will have to wait more.

 

VMware sticks finger in Meltdown/Spectre dike for virtual appliances
Proper patches under way, but for now - to your command lines, vAdmins!
By Simon Sharwood, APAC Editor 9 Feb 2018 at 03:58

"VMware has advised on how to mitigate the Meltdown and Spectre chip design flaws in several of its products.

The workarounds cover vCloud Usage Meter, Identity Manager (vIDM), vCenter Server, vSphere Data Protection, vSphere Integrated Containers and vRealize Automation (vRA). And they're important because VMware now ships several of its products as appliances: vCenter, for example, is no longer allowed to run in a Windows VM.

The knowledge base articles for all the products state that Meltdown and Spectre can create problems for virtual appliances, explain that the mitigation tactics will stop attacks but must be considered "a temporary solution only and permanent fixes will be released as soon as they are available."

Several of the workarounds, listed here, require logging on as a privileged user and then type a couple of commands. Others require more effort. So crack open your command lines, vAdmins: there's work to do.

And in case you are super-keen on VMware and or wonder about what Dell plans to do with it , consider its SEC filings and those of the Dell Technologies tracking stock that's tied to Virtzilla.

Both record that colossal investment management outfit Blackrock Inc has recently increased its holdings in both stocks above the five per cent level that makes public disclosure compulsory. That kind of buy is sometimes a signal that an investor wants its opinions to be given greater weight.

So once you finish your workarounds, grab some popcorn."

 

I think the Skylake Spectre-fixed microcodes are just identical to the previously pulled release, at least according to this Intel documentation. If you notice there are 3 *** (stars) next to the microcode for Skylake in the following document ( https://newsroom.intel.com/wp-content/uploads/sites/11/2018/02/microcode-update-guidance.pdf) - the 3 stars indicate that it was the previously released microcode and that the stability issues were initially incorrectly linked to the microcode - so initial fixed microcode is stable on Skylake, which can be inferred by that document. 0xC2 is the fixed microcode. That's probably why Skylake are the first to receive stable microcodes sent to the OEM's for incorporation into future BIOS releases, which has been in the news that you linked, because it's just identical to the previous release that had been pulled (no extra work required on part of Intel).

 

Get Windows Update locked down in preparation for this month’s problems-Computerworld.com

If February turns out half as bad as January, you’ll thank your lucky stars if you take a few minutes now and make sure Windows Update is turned off. Temporarily, of course.

Security luminary Brian Krebs has already reported that we’re in for a potful of patches for February’s Patch Tuesday. His list of ten critical patches due out tomorrow should give you pause.

If you find a security “expert” who tells you to turn on Automatic Updates after all the hassles we had last month, send ‘em to the AskWoody Lounge and we’ll knock 'em upside the head. Those who don't know history are destined to repeat it

 

Regardless, it doesnt sound good for Intel