Intel bug incoming.

ralphbsz,

I think you are referring to an IBM Thinkpad which was a laptop computer. The spectre flaw is endemic in the industry as a whole and requires a rethink of CPU design across the board. The meltdown bug is aimed straight at Intel though because they were playing fast and loose with the rules to get a performance advantage over their competitors. To be fair, some ARM chips are also vulnerable to meltdown. In general, this is a new class of attacks. The concepts have been around for awhile but were generally considered to be theoretical, until now.

The number one priority for any company is to make money. Spending money to fix a theoretical exploit which has not been proven was considered to be a bad business decision. However, AMD bit the bullet and fixed it anyways. Now that the roosters have come home to roost at Intel, their 'good' business decision has turned a theoretical problem into an unmitigated disaster. Their PR department is trying to put so much spin on the issue that their Santa Clara, CA facility has spun up to the point that there is now a permanent cyclone over Silicon Valley which will not dissipate any time soon.

Actually, you can avoid Intel products at a large scale. Just don't buy anything with an Intel CPU in it. My HP laptop which I bought a week before news of the flaws broke has an AMD chip in it. So yeah, AMD hardware is out there, and right now it's looking more attractive than ever.
 
Really quick (done with lunch, have to go back to work): I'm not talking about laptops at all, nor about computers that individuals own. A very large fraction of all CPUs made is *not* used by individuals or consumers, but by enterprise users (General Electric/Motors/Atomics/...), internet-scale operations (Google/Facebook/...), and government agencies (no such agency, central international airlines, natural walrus office, ...)
 
Snurg , there is a small bug in your program, here is a patch
Code:
--- intel.c     2018-01-21 15:37:00.232218000 -0700
+++ intel.c     2018-01-21 15:38:07.218179000 -0700
@@ -260,7 +260,7 @@
     strcpy( fpath, path);
   }
   /* now the shared section: read update file name and verify its format is valid */
-  if ((r = ((updfd = open(fpath, O_RDONLY, 0)) < 0))) {
+  if ((r = ((updfd = open(updatefpath, O_RDONLY, 0)) < 0))) {
     INFO( 10, " Failed to open %s file\n", fpath);
   } else
     r = 0;
 
aragats Thanks, fixed this and other small things while making the actual updating work and adding nicer output also.

By the way, the cpudev-data port added an -e option, which re-reads the processor feature flags. But this requires kernel update, thus cannot be used on older FreeBSD versions.
I wonder whether this is necessary when processor stats do not change?
I did update the microcode on my running system and didn't notice anything going bad...
So, could there be a problem with not re-reading the flags if they stay the same anyway?

Will upload new version onto Github in 1, 2 hrs.
 
I did update the microcode on my running system and didn't notice anything going bad...
I did update too, but the latest microcode file for my i7-3520M is dated Feb 2015! It looks that they are not going to update Ivy Bridge...
Nothing bad is noticed so far.
 
I hate to ask questions, but I recently acquired a T43 with a Pentium M 760 @ 2.00GHz Dothan. I've looked around and nowhere have I seen Pentium M mentioned as being among those vulnerable. It does show N:

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr

I know that can change at any time and am aware they're saying almost everything back to the PII is vulnerable.

All my others are effected and probably won't get patched, I'm not yet sure what I'll do about that. It would be nice if this old underpowered box wasn't, but I'm not getting my hopes up.
 
Breaking: Intel released an official document about which microcodes to use and which ones not to use.

Edit: Somebody, I think ralphbsz mentioned the problem of potentially crafted microcodes being created and used maliciously. I just found an analysis of the Intel microcode encryption behaviour here.

Edit 2: Now Intel says they have identified the root cause of the "mysterious" reboots. But they did not reveal any details.
However, it is known that if the Intel Management Engine is being deactivated incorrectly this will cause exactly such reboots.
Thus I think it could be perfectly safe to assume that the reboot problem is related to the IME.

If this is the case, it would make sense being secretive about that, because that thing can be used as a powerful hyper-hypervisor, nicely usable for surveillance software like the Bundestrojaner (German wiki link), for example.
Maybe this thing is the reason why Dell now begun offering computers with deactivated IME (Link in German) to be safe from such espionage and surveillance tools, albeit only for US customers.
 
The google news headline says:
Linux Torvalds declares Intel fix for Meltdown/Spectre "Complete and utter garbage"

Sorry, don't have time to read it right now, have to deal with a plumbing problem (circulator pump failed). Sounds amusing.

Edited to add: A quick peek while waiting for the pump housing to be cleaned by aggressive acids (!) shows that Linus also calls Intel "f***ing insane". Important life lesson here: Only buy stainless pumps if you have hard water.
 
Some more entertainment from the Intel comedy theatre:

The Linux devs are foaming because Intels botched microcode updates forces them to implement a microcode blacklist, as some reported processor features are buggy and must not be used in case the update has already been installed in the BIOS.
Probably this was the reason why Intel finally decided to release that list with the microcodes not to use I posted in my last post.
(Btw, I was unable to find that document on the public Intel newsroom. I suppose Bing probably has found it via some link deep in the Intel developers' forums.)

The microcode updates by Intel as well as by AMD actually add three new processor "features" STIBP, IBPB and IBRS, which afaiu take care that cpu caches etc are purged so that alternative tricks like multiply nested calls that also can be used to exploit do no longer work. An Amazon Linux developer explained quite well here what these features do.

However, as using these features imposes a huge performance impact of about 4000 cycles when changing privilege levels, Linus exploded on Intels "utter garbage" when it was suggested to use these features.
RedHat already went forward and implemented that stuff, but made it a non-mandatory tunable.

Regarding FreeBSD, these new "features" are at least in the processor feature recognition code. I hope the devs will make them non-default tunables like RH. It would suck so much bogging down the performance just to save botched designs like Skylake.

Edit: I see ralphbsz was a bit faster than me :beer:
 
Regarding FreeBSD, these new "features" are at least in the processor feature recognition code. I hope the devs will make them non-default tunables like RH. It would suck so much bogging down the performance just to save botched designs like Skylake.

Edit: I see ralphbsz was a bit faster than me :beer:

Considering the FreeBSD developers are quite sane when implementing the code, I think that they will take the common sense approach. The way that I see it, trap.c will have to make a decision as to which way to go when dealing with the KPTI-FUCKWIT settings to mitigate the meltdown bug. For the spectre bug, that only really applies to virtual machines and any kind of interpreted code such as Python, Java, or JavaScript.


I read it. The gist of it is that Intel submitted patches that fixed not only meltdown, but other things as well which were already fixed. I'm not sure why they felt they needed to do that, but who knows.
 
Interesting, is it possible to implement Google Retpoline solution for Spectre 2 widely, for for all existing OSes?
 
Linux 4.16 kernel now has released, with its Retpoline solution.
However, Retpoline alone will apparently not be sufficient to protect virtual machines against Spectre, according to what I read on German IT site golem.de.
As it now slowly emerges that Intel only works on microcode fixes for Skylake, Haswell and Broadwell, but not for older generations, it looks like that Intel's original promise to deliver microcode updates for all affected processors was just a trick to calm down the waves.
From private email conversations with Intel staff it now seems quite certain that processors Westmere and older generations will never get microcode updates.
Whether pre-Haswell generations (Sandy Bridge, Ivy Bridge, Silvermont) will get microcode updates at all is still unclear, as the newer ones have priority.
This in turn could mean that pre-Haswell users will never be able to protect against Spectre.

We FreeBSD users will have to wait for a fixed OS until at least Jun 27, 2018, as the yesterday-published release schedule for 11.2 reveals. :(
 
I find it ironic that they are still using the marketing phrase "Expereince what's inside". :p

So basically, if I want to experience Intel, in addition to forking over lots of cash, I also have to bend over for any hacker that wants to penetrate my security.... ;)

I don't think so.
 
So basically, if I want to experience Intel, in addition to forking over lots of cash, I also have to bend over for any hacker that wants to penetrate my security.... ;)

I don't think so.
Unbidden memories from watching pulp fiction enter my mind. And it is just after breakfast.
 
Is this for real? Arent they releasing a fix as a patch level for 11.X? (and maybe even 10.X)

Unfortunately, it is. For now, just be careful what you run or run on AMD hardware. There's a lot of rework in the way the kernel handles paging to resolve this issue. It's really tricky code that hasn't been touched it years.
 
Back
Top