# Intel bug incoming.



## rigoletto@ (Jan 2, 2018)

*Intel Bug Incoming*.

EDIT:

It seems sh!t will get pretty serious:

*Intel's CEO Just Sold a Lot of Stock*

UPDATE:

*'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign*


----------



## Avernar (Jan 2, 2018)

Here's the story with some info:  https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

I did some quick searches but didn't find anything regarding a FreeBSD patch.


----------



## SirDice (Jan 2, 2018)

Nobody even knew the bug existed until a few hours ago.

(threads merged)


----------



## Avernar (Jan 2, 2018)

SirDice said:


> Nobody even knew the bug existed until a few hours ago.


Looks like the Linux and Windows kernel devs knew as there has been hush hush work on it.  The email (and patch to not turn on the fix and associated performance hit for AMD CPUs) from AMD saying they're not affected is dated Dec 26th.

I was just wondering if there was similar under the radar activity in the FreeBSD kernel, or any *BSD kernel for that matter.


----------



## Avernar (Jan 2, 2018)

From http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table:

"From a little digging through the FreeBSD source tree, it seems that so far other free operating systems are not implementing page table splitting"


----------



## fullauto2012 (Jan 3, 2018)

SirDice said:


> Nobody even knew the bug existed until a few hours ago.
> 
> (threads merged)



People have been redacting comments in source code...
Some knew.

It would be helpful for some of the senior members (or one) to do a QUAD (Quick And Dirty) rundown of what this is, and how it affects FreeBSD users... Green Beans, such as myself, could really use it...


----------



## rigoletto@ (Jan 3, 2018)

I think any public information should just appear after the end of the embargo.


----------



## Snurg (Jan 3, 2018)

SirDice said:


> Nobody even knew the bug existed until a few hours ago.


Maybe nobody in the general public...

The theregister article has a link to a blog post by Anders Fogh, describing the bug back in July already.
Microsoft beta-tested the upcoming patch already since Nov., according to the article.
The KAISER project documentation hints vaguely to a Linux bugfix commit 2 yrs ago by Intel against row-hammering, in a way that could hide the true intention behind the KAISER project to not make people more curious than necessary.

But the most amazing thing is that *this exploit technique was known already since Jan. 1967*, 51 years ago.
Yes, 1967. No typo. Read Fogh's blog post for more info.

As OpenBSD devs aren't permitted to sign NDA's, it's quite clear that the BSD community in the eyes of Wintel is not a "reliable" clientele you can tell secrets like this.
I guess there will be some quick action from Raadt&co, which the other BSD's will follow.


----------



## Deleted member 30996 (Jan 3, 2018)

Snurg said:


> As OpenBSD devs aren't permitted to sign NDA's, it's quite clear that the BSD community in the eyes of Wintel is not a "reliable" clientele you can tell secrets like this.
> I guess there will be some quick action from Raadt&co, which the other BSD's will follow.



I was wondering how the OpenBSD 6.2 implementation of KARL would fare against this.


----------



## Avernar (Jan 3, 2018)

Trihexagonal said:


> I was wondering how the OpenBSD 6.2 implementation of KARL would fare against this.


From the article: "If you randomize the placing of the kernel's code in memory, exploits can't find the internal gadgets they need to fully compromise a system. The processor flaw could be potentially exploited to figure out where in memory the kernel has positioned its data and code, hence the flurry of software patching."


----------



## Datapanic (Jan 3, 2018)

And that's why I still have NetWare 4.11 and DOS 6.22 clients running Windows 98!


----------



## Deleted member 30996 (Jan 3, 2018)

Avernar said:


> From the article: "If you randomize the placing of the kernel's code in memory, exploits can't find the internal gadgets they need to fully compromise a system. The processor flaw could be potentially exploited to figure out where in memory the kernel has positioned its data and code, hence the flurry of software patching."



Yes, I read the article:



> Specifically, in terms of the best-case scenario, it is possible the bug could be abused to defeat KASLR: kernel address space layout randomization. This is a defense mechanism used by various operating systems to place components of the kernel in randomized locations in virtual memory.


http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

That's why I asked about KARL.



> KARL should not be confused with ASLR -- Address Space Layout Randomization -- a technique that randomizes the memory address where application code is executed, so exploits can't target a specific area of memory where an application or the kernel is known to run. A similar technique exists for randomizing the memory location where the kernel loads -- called KASLR. The difference between the two is that KARL loads a different kernel binary in the same place, while KASLR loads the same binary in random locations.



https://tech.slashdot.org/story/17/07/05/2327234/openbsd-will-get-unique-kernels-on-each-reboot

Looking at it now I suppose it doesn't make any difference.


----------



## Beastie7 (Jan 3, 2018)

Very concerning times with these hardware exploits. All I can say is.. this is going to turn out well for AMD.


----------



## Avernar (Jan 3, 2018)

Trihexagonal said:


> Looking at it now I suppose it doesn't make any difference.



Yup.  The reason why both KARL and KASLR work is because you have to guess where things are.  And then you need to use an exploit to write into kernel memory to do your exploit.  Guess wrong and you crash the machine.

But since this exploit allows you to read kernel memory there's no need to guess and both techniques are defeated.  You figure out where things are using the exploit and then pull out the juicy bits (encryption keys, api keys, auth tokens, etc) using the same exploit.


----------



## Avernar (Jan 3, 2018)

Beastie7 said:


> Very concerning times with these hardware exploits. All I can say is.. this is going to turn out well for AMD.


I just put together a box with a Ryzen CPU so I'm very happy with that decision.  My other FreeBSD box is a Core i5 so that's the only one here I have to worry about.

The situation at work is going to be more interesting however...


----------



## rigoletto@ (Jan 3, 2018)

Beastie7 said:


> Very concerning times with these hardware exploits. All I can say is.. this is going to turn out well for AMD.



I think 2018 will be an EPYC year.


----------



## Snurg (Jan 3, 2018)

Trihexagonal said:


> That's why I asked about KARL.
> Looking at it now I suppose it doesn't make any difference.


I am a kernel layman, so I could be totally wrong.

I think KARL still makes a difference. Because, if I understand correctly, the basic "protection" principle was to hide the kernel somewhere in the big virtual address space.
If by some trick you manage to find out this address space, you might able to read-scan that memory range for interesting things like passwords, buffers etc., without causing a privilege exception.
As most people use generic kernels, the location of all that stuff is well-known if you manage to find a single fixed kernel address.

I guess this approach could be more difficult, when like with KARL the kernel modules are sprayed over the virtual address space. If you manage to find where _one _module is, this is probably of far less value, when you would possibly have to run multiple attacks on different functions/modules to get substantial information.
But as said I might be wholly wrong.

Edit: yes, I confused some things...   a combination of KASLR and KARL would be desirable.


----------



## Avernar (Jan 3, 2018)

Snurg said:


> hide the kernel somewhere in the big virtual address space


Hmm, I wonder if the exploit is limited to just reading memory.  Because "mov cr3, rax" would make finding things really easy.


----------



## ralphbsz (Jan 3, 2018)

Snurg said:


> But the most amazing thing is that *this exploit technique was known already since Jan. 1967*, 51 years ago.
> Yes, 1967. No typo. Read Fogh's blog post for more info.


No, I think you are exaggerating.  In 1967, Tomasulo (I've never met him) published a paper that describes how the IBM 360/91's CPU worked; that was one of the first CPUs that had multiple execution units (it could load, store, calculate, chew gun, rub its tummy, and walk at the same time).  The machine was actually designed years earlier (it was an "echo" of the IBM Stretch, the eventually cancelled super-computer that nearly bankrupted IBM).  It was heinously complex, and ridiculously fast (for its age), and really pushed the state of the art.  But in those days, nobody would have worried about security issues, like one process trying to use side-channels (like measuring instruction timing) to find out where the kernel is located in memory.  In those days, programs were only run by people in white lab coats, who had good access to the machine documentation (ever read the IBM 360 POO, the best documentation ever written?), and had complete source code of the operating system (it used to ship to customers on micro-fiche).  Hacking didn't exist yet.  Tomasulo didn't worry about security, he worried about making the machine reliable, correct, and fast.


----------



## rigoletto@ (Jan 3, 2018)

If this thing is deep as it seem to be, do you think we may start to see more POWER{8,9} available/support around?


----------



## ralphbsz (Jan 3, 2018)

What makes you think that Power (or Sparc or Itanium or Arm or ...) doesn't have equivalent bugs, which just haven't been found because they are used and tortured less?  Or which haven't been discussed in public?  Are there any people not on IBM/Oracle/HP/... payroll which develop kernels for these architectures?


----------



## Snurg (Jan 3, 2018)

ralphbsz said:


> Tomasulo didn't worry about security, he worried about making the machine reliable, correct, and fast.


You are correct in the sense nobody thought of "exploits" back then as _reliability and correctness issues_.
But what strikes me is that these _basic reliability and correctness issues, _as you have put it very well, related with multiple ALU/EU that were discovered back then already, seem to have been overlooked by Intel when they designed similar machines decades later again, just in micro scale...


----------



## Maelstorm (Jan 3, 2018)

I saw this in the news today:

https://gizmodo.com/report-all-intel-processors-made-in-the-last-decade-mi-1821728240
http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table

So it seems that there is some kind of memory leakage from kernel space to user space and the fix requires the purge of all kernel address space information from the TLB, which incurs a major performance hit.

How is FreeBSD handling this?

EDIT:

Here's some more links:

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
https://lkml.org/lkml/2017/12/27/2


----------



## SirDice (Jan 3, 2018)

Lets keep it all in one thread, merged.


----------



## PacketMan (Jan 3, 2018)

Avernar said:


> I just put together a box with a Ryzen CPU so I'm very happy with that decision.  My other FreeBSD box is a Core i5 so that's the only one here I have to worry about.



Hmm, I wonder if I can return my just-bought-yet-to-be-delivered Intel based hardware, and exchange it for AMD based system.  This story pretty much states all Intel CPUs made in the last year.


----------



## Gray Jack (Jan 3, 2018)

Kernel Page Table Isolation Is a cool name, but I prefer Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka FUCKWIT
x86 fuckery at it's finest xD


----------



## Maelstorm (Jan 3, 2018)

SirDice said:


> Lets keep it all in one thread, merged.



I didn't know there was already a thread created for this.


----------



## SirDice (Jan 3, 2018)

No worries, I needed to exercise my merging skills anyway


----------



## Maelstorm (Jan 3, 2018)

Avernar said:


> I just put together a box with a Ryzen CPU so I'm very happy with that decision.  My other FreeBSD box is a Core i5 so that's the only one here I have to worry about.
> 
> The situation at work is going to be more interesting however...



No kidding.  All of my currently active computers are AMD based.  I have one Core2Duo based machine that does not have the problem.



lebarondemerde said:


> I think 2018 will be an EPYC year.



Hahaha...  More like *EPIC FAIL* on Intel's part, which is not a laughing matter.  Another halt and catch fire situation.  How do you not do security checking on speculative execution...because if the branch is taken, you are going to need to do the checks.  That's some real talent there over at Intel.  I wonder what other problems that Intel chips have that they are not telling us about.

Remember the F00F bug in the original Intel Pentium?  I have one of those machines.  There was an anonymous post to comp.os.linux.advocacy usenet group that sent everyone scrambling for a fix.  Then there was the Intel Pentium FPU bug where a lookup table was missing six entries.  A researcher who noticed the problem tried to tell Intel about it and they brushed him off.  Then is posted it on a public forum, and Intel contacted him within hours.

So, this isn't the first time Intel chips have had bugs, and it most definitely will not be the last.



PacketMan said:


> Hmm, I wonder if I can return my just-bought-yet-to-be-delivered Intel based hardware, and exchange it for AMD based system.  This story pretty much states all Intel CPUs made in the last year.



Actually, from what I have read, all Intel CPUs made within the past *DECADE*, which is a lot.



Gray Jack said:


> Kernel Page Table Isolation Is a cool name, but I prefer Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka FUCKWIT
> x86 fuckery at it's finest xD



To error is human, to really foul things up requires a computer.  Seriously though, I think that is something to consider when naming a patch.  I wonder who is going to get blamed for this.


----------



## gofer_touch (Jan 3, 2018)

Terrible. Looks like Intel's performance lead over the competition all these years was because they were cutting corners on security. The purported fix for this has been shown to result in a 30% decrease in CPU performance. I can see some cloud providers going under over this. They operate very narrowly within performance specs to cut costs, a 30% drop in performance is quite massive. 

Milk it AMD! Ramp up the POWER9's IBM!


----------



## Maelstorm (Jan 3, 2018)

fullauto2012 said:


> People have been redacting comments in source code...
> Some knew.
> 
> It would be helpful for some of the senior members (or one) to do a QUAD (Quick And Dirty) rundown of what this is, and how it affects FreeBSD users... Green Beans, such as myself, could really use it...



I do not fully understand the mechanism myself of what the bug is, but I'll share what I know.

When a process is started, the kernel memory space is mapped into the process memory space.  Although it's there, due to flags that are set on the pages occupying the kernel memory, a process cannot directly access it.  This is done for performance reasons so the CPU will not have to reload the page table into the translation lookaside buffer (TLB) when a process requests kernel services such as I/O.  The reason for this is that a full context switch is expensive because the CPU must switch from one address space to another.  With the kernel memory within the process address space, the full context switch is not necessary.

This is a guess, but the bug seems to deal with security checks during speculative execution when performing branch prediction.  I do not know how or quite understand the mechanism behind it, but using a side-channel attack, a mitigation technique called Address Space Layout Randomization (ASLR) is rendered ineffective.  ASLR is a technique where each time a process is executed, the locations of various components are in random locations within the virtual memory space of that process.  So each time a process is executed, things such as program code, shared libs, stack, data, heap, kernel, etc... are in different places.  It's up to the loader to resolve this so the program can run.  The implications of this is that an attacker can find out the locations of things in memory to press other attacks, primarily return address attacks.  But other exploits are possible with the main concern of being able to read kernel memory.  Kernel memory is full of sensitive information which is why this is such a big deal.

Here is a link to an image demonstrating ASLR.
http://www.worldnews.easybranches.c...ws-aslr-bug-is-intended-feature-microsoft.jpg

Also, apparently this is considered the mother of all privilege escalation bugs for virtual machine hypervisors.

Now, the current fix is to completely remove the kernel memory space from the process memory map, which completely severs the link between the process and the kernel.  So when a process needs kernel services, or an hardware interrupt fires, a full context switch is required.  That takes much more time and can incur a performance penalty of 30% or more.  An example that I read found that there was a 50% performance hit for `du`.  The reason for this is that the TLB and caches are dumped and accesses are performed directly to main memory until the caches fill up.  When a process references an address that is within a page that is not in the TLB, two main memory accesses are required: First one for the page table lookup, the second one for the actual memory reference.  Since main memory nowadays has an access time of something like 20ns, and cache memory is like two orders of magnitude faster, you are looking at an additional 200 clock cycles of time required for cache misses, which incur a massive performance penalty.

In case anyone is wondering, the TLB is the cache for the memory management unit which resides on the CPU die along with the instruction and data caches.  It holds a subset of the page table which maps physical memory addresses to virtual memory addresses.

AMD has come out and said that their processors are not vulnerable to this exploit.

This is my understanding of the situation, which will most likely change when more information becomes available.

EDIT:

Some new info.  Apparently the bug is in the memory fetch hardware, does not do security checking for speculative execution, and irrevocably modifies the cache.  The memory fetch hardware operates below the microcode and cannot be fixed as it's wired logic.  Looks like Intel was cutting corners to save some transistors and gain a small performance increase and it bit them, hard.  It seems that AMD chips throws an exception if the memory fetch encounters a security failure, speculative execution or not.

EDIT:

It's a timing attack on the speculative execution for out of order processors.  By using the timing, an attacker can determine if something is or isn't in the cache.  Somehow, they are able to determine where the kernel is mapped in the process address space and can apparently read that kernel memory as well.  And it gets worse.  They can also read memory that belongs to other processes.  This means that the fix is to completely isolate the pages tables from each other.


----------



## Snurg (Jan 3, 2018)

Maelstorm said:


> I Apparently the bug is in the memory fetch hardware, does not do security checking for speculative execution, and irrevocably modifies the cache.


And reading the cache line itself does not cause exceptions?
Or maybe there is some so-called "undocumented function" or another trick that allows this unprivileged?

Edit: I am smiling at the thought what it might cost Intel when people learn that they wittingly sold faulty processors and want refunds or even damages


----------



## PacketMan (Jan 3, 2018)

Maelstorm said:


> Actually, from what I have read, all Intel CPUs made within the past *DECADE*, which is a lot.



Yeah that is what I meant to say; didn't have me 2nd tea drank then.  



gofer_touch said:


> The purported fix for this has been shown to result in a 30% decrease in CPU performance. ....Milk it AMD! Ramp up the POWER9's IBM!



One of the guys here at work said because of the nature of the patch, AMDs will suffer the performance hit too, even though their CPUs do not have this issue.  Is there any truth to that?  I was able to RMA my just-bought-yet-to-be-delivered Intel based hardware so I want to understand what this means exactly before I make my 2nd try purchase.  Are there any other URLs a fellow can latch onto?  Maybe we will see all the dirty bath water by end of the week or next?


----------



## MarcoB (Jan 3, 2018)

Hmm, past decade? My cpu's are 14 years old. I wonder if this machine is affected...


----------



## Deleted member 30996 (Jan 3, 2018)

Snurg said:


> I am smiling at the thought what it might cost Intel when people learn that they wittingly sold faulty processors and want refunds or even damages



Remember when the Intel Katmai PIII had the Processor Serial Number that could identity your computer and activities, and how people thought it was a 3 letter agency backdoor?

https://slashdot.org/story/99/01/25/0913233/intel-psn-boycott-planned

I still have my 500MHz Katmai.


----------



## MarcoB (Jan 3, 2018)

Probably a good idea to keep those old obscure computers just in case...


----------



## rigoletto@ (Jan 3, 2018)

I am wondering how all those business who bought thousands and thousands of Intel based servers will react... They certainly will want to be compensated by the performance hit and the extra power consumption. They will need more servers ASAP to do the same they did prior the bug.

I would not be surprised by a RIP Intel in a near future.

Fortunately, the only Intel hardware I have is a Core2Quad.


----------



## rigoletto@ (Jan 3, 2018)

PacketMan said:


> One of the guys here at work said because of the nature of the patch, AMDs will suffer the performance hit too, even though their CPUs do not have this issue.  Is there any truth to that?  I was able to RMA my just-bought-yet-to-be-delivered Intel based hardware so I want to understand what this means exactly before I make my 2nd try purchase.  Are there any other URLs a fellow can latch onto?  Maybe we will see all the dirty bath water by end of the week or next?



I guess in the first moment yes, but as soon it happens AMD should lobby to something like separate: _patched for Intel, and not patched for AMD_.

EDIT:
Also, crippling the AMD performance without the need could potentially lead to some serious legal issues, as it could be interpreted as a handout to Intel.

In some jurisdictions this kind of practice can be interpreted as a criminal practice.


----------



## MarcoB (Jan 3, 2018)

Well the ceo of Intel sold a lot of his stock on nov. 29th. So that transaction will be investigated I guess. And 2018 will be a good year for AMD.


----------



## rigoletto@ (Jan 3, 2018)

MarcoB said:


> Well the ceo of Intel sold a lot of his stock on nov. 29th. So that transaction will be investigated I guess. And 2018 will be a good year for AMD.



I hope POWER9 gets a lot of traction with that too, however it drain a lot of more power than x86 (at least the POWER8).

I would love to have a POWER9 (OMG, up 8 threads per core) workstation. I mean, one I could run everything I run now with my AMD hardware.

Btw,  PPC is Tier 2 in FreeBSD, for now I hope.


----------



## Eric A. Borisch (Jan 3, 2018)

lebarondemerde said:


> I guess in the first moment yes, but as soon it happens AMD should lobby to something like separate: _patched for Intel, and not patched for AMD_.



You mean like this: https://lkml.org/lkml/2017/12/27/2 ?


```
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
arch/x86/kernel/cpu/common.c |    4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index c47de4e..7d9e3b0 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -923,8 +923,8 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c)

     setup_force_cpu_cap(X86_FEATURE_ALWAYS);

-    /* Assume for now that ALL x86 CPUs are insecure */
-    setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
+    if (c->x86_vendor != X86_VENDOR_AMD)
+        setup_force_cpu_bug(X86_BUG_CPU_INSECURE);

     fpu__init_system(c);
```


----------



## rigoletto@ (Jan 3, 2018)

Another important sub-subject is how much the FreeBSD patches will affect the performance? Specially comparing with the Linux one.

It seems the Linux should be hit by up to 30% depending on hardware, but I already saw some people saying it can go up to 50%.

If the FreeBSD solution could keep the performance hit at considerable lower numbers than Linux, I see a quite potential market grow for FreeBSD.


----------



## gnoma (Jan 3, 2018)

Software bugs can be fixed with patch from the developers and simple update.

Hardware bugs however affect already manufactured and released to the market hardware.

And because it's so widely used it cannot be simply pulled of the market and replaced.
And again because it's so widely used the kernel developers have no choice but to wipe Intel's ass and try to workaround it via software patch.
And because a patch will be released and issue will be somehow fixed there will probably not be needed to switch to AMD. This means that Intel will survive this crisis.

However what troubles me are the following questions (one of them asked above)

1. Will there be a workaround that will reduce the performance degradation and make it insignificant? I guess we will need to wait and see. Probably the least Intel can do is assisting the kernel developers with whatever hints they would need. 
2. Will the AMD CPUs suffer the same performance degradation because of intel's epic fail and kernel's general redesign?

The only scenario that will cause huge losses for Intel is only if the brutal performance degradation cannot be avoided && the kernel redesign wouldn't affect the AMD CPUs.

And even if this happens when you are buying a new CPU you would still have a choice - new fixed Intel CPU (because it will probably take only few months for Intel to fix  this in their new CPUs), or a new AMD that is not affected by the performance, or the security issue.
Or so to speak this affects only the sold CPUs of Intel and they already got the money : )))


----------



## MarcoB (Jan 3, 2018)

The Linux folks fixed it by implementing kernel page table isolation. As far as I can tell all os's are fixing it this way. But maybe FreeBSD has this already to some degree in the kernel? If so maybe the performance hit isn't that big.

I'm really interested what the reaction of the FreeBSD folks will be.


----------



## PacketMan (Jan 3, 2018)

When an OS is installed on a platform, it has to determine the CPU hardware type correct? So wouldn't the patch only be needed for Intel?  (I can't take my hard drive now as it running on a Intel machine, and stick it in an AMD machine and it will still work right?)  Also, can they actually build a 2nd (revised) flavor of the CPU? Can the patch code determine rev a versus rev b and thus would not actually be executed for rev b cpus?  Sorry I'm not a hardware guy so my questions might seem trivial.


----------



## MarcoB (Jan 3, 2018)

If you look at your dmesg, the kernel is able to tell exactly what type cpu the machine has. So seems to me that a patch can be made for the right cpu, and exclude the ones that don't need the fix.


----------



## firmx4 (Jan 3, 2018)

Eric A. Borisch said:


> You mean like this: https://lkml.org/lkml/2017/12/27/2 ?


FOSS software is FOSS sofware. Amazon, Microsoft and other cloud-providers can always write some patches themself to disable KPTI for AMD hardware.
To disable KPTI regular users can always user  "_nopti_" boot time option.
I am curious how Intel communicates with FOSS OSes developers about the vulnerability. Of course I am most interested in *BSD family of OSes.


----------



## rigoletto@ (Jan 3, 2018)

firmx4 said:


> FOSS software is FOSS sofware. Amazon, Microsoft and other cloud-providers can always write some patches themself to disable KPTI for AMD hardware.
> To disable KPTI regular users can always user  "_nopti_" boot time option.
> I am curious how Intel communicates with FOSS OSes developers about the vulnerability. Of course I am most interested in *BSD family of OSes.



I do not know about the *BSD (bur probably similar situation) but many Linux (kernel) developers are Intel employees.


----------



## Avernar (Jan 3, 2018)

Maelstorm said:


> The reason for this is that the TLB and caches are dumped and accesses are performed directly to main memory until the caches fill up.  When a process references an address that is within a page that is not in the TLB, two main memory accesses are required: First one for the page table lookup, the second one for the actual memory reference.


I don't believe that the caches other than the TLB are flushed.  With the kernel no longer in the page tables the speculative load bug would not be able to modify the caches with kernel data anymore.

A a TLB miss requires 4 extra memory access for a total of 5 in 64-bit long mode for a 4K page.  That's why this hurts performance so much.


----------



## Avernar (Jan 3, 2018)

Proof of Concept for an exploit: https://twitter.com/brainsmoke/status/948561799875502080


----------



## MarcoB (Jan 3, 2018)

Intel responds, it's not a bug!:
https://newsroom.intel.com/news/intel-responds-to-security-research-findings/


----------



## Datapanic (Jan 3, 2018)

MarcoB said:


> Intel responds, it's not a bug!:
> https://newsroom.intel.com/news/intel-responds-to-security-research-findings/



I think they just said it's a "feature".


----------



## cpm@ (Jan 3, 2018)

https://lists.freebsd.org/pipermail/freebsd-security/2018-January/009651.html


----------



## _martin (Jan 3, 2018)

Nice introduction to the problem: https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/


----------



## ShelLuser (Jan 3, 2018)

Beastie7 said:


> Very concerning times with these hardware exploits. All I can say is.. this is going to turn out well for AMD.





MarcoB said:


> Well the ceo of Intel sold a lot of his stock on nov. 29th. So that transaction will be investigated I guess. And 2018 will be a good year for AMD.


Highly unlikely.

What is most likely going to happen (so I think, hope to be proven wrong) is that in roughly 2 months time everyone will have forgotten all about it. "Some" operating systems(?) will even have slowed down their processing in order to mimic an actual patch and everyone will continue on and no one will bother anymore.

See: I see resemblances with an open source mess up. Debian OpenSSL disaster anyone? Where a package maintainer knowingly and willingly messed up and basically broke OpenSSL to such extends that some ISP's (GoDaddy comes to mind) decided to revoke ALL Linux based certificates issues in the past years and either refund or rebuild the certs).

In an open source community I would have expected that moron to get fried and thrown out of the project. Not necessarily as a public spectacle but at least have him fess up for his incompetence. But to my knowledge none of that happened. He simply get doing his thing as if nothing had happened. _Yaaay_.

If that's how things work within the world of open source do you really expect a different result in the real world?

I sure don't (unfortunately).


----------



## _martin (Jan 3, 2018)

And some more info: https://meltdownattack.com/


----------



## rigoletto@ (Jan 3, 2018)

It is out: HERE.

EDIT:

Well, too late. _martin was faster. 

EDIT_2: Reading Privileged Memory with Side


----------



## Maelstorm (Jan 3, 2018)

Avernar said:


> I don't believe that the caches other than the TLB are flushed.  With the kernel no longer in the page tables the speculative load bug would not be able to modify the caches with kernel data anymore.
> 
> A a TLB miss requires 4 extra memory access for a total of 5 in 64-bit long mode for a 4K page.  That's why this hurts performance so much.



The main CPU cache is probably not flushed, but because the physical addresses are different, there will be a whole slew of cache misses until it is populated with the new data.  So, in effect, the cache is flushed.  However, to mitigate the slowdown, one could preload the cache with the new data.  I can see a fundamental architecture change in the way that x86 works which may break backwards compatibility with older software.  One other thing to consider too is that CPUs have different instruction and data caches.  I could see how Intel would not be doing security checks for data already in the cache.


----------



## _martin (Jan 3, 2018)

And one more, from the source:  googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html

I won't add more as I'm guessing 'internets' will be full of it very fast.

lebarondemerde : yeah, but you were close


----------



## Snurg (Jan 4, 2018)

So my impression for now:
This speculative execution exploit feature permits interested people/programs to probe memory addresses.
The timing then reveals whether a particular virtual memory address block actually is mapped or not.

This cool Intel processor feature enables one to do this without causing unwanted exceptions.

I am still reading the Meltdown paper.
Imho an average kernel memory read data rate of about 1/2 MB/sec is not bad.

If the kernel is one big chunk of data and not many small ones sprayed over the address space, then I guess this could be the standard approach:

1. scan the virtual address space with increments of about half kernel size.
2. as soon as mapped memory has been found, find its start/end addresses
3. Finally walk through the kernel memory and retrieve the interesting things (accounts, certs, ...)


----------



## Maelstorm (Jan 4, 2018)

Now that more information has come to light about the bug, this definitely has to do with speculative execution.  What I have found out this:  An attacker can use the time it takes the CPU to execute a speculative set of instructions before it is known if a branch is to be taken or not to find out where the kernel memory is in the process address space.  And the bug is actually more serious than that.  By using this technique, an attacker can actually read kernel memory, which contains all sorts of useful information.  They can even use this attack to read memory from a different process, breaking process isolation.  So yeah, this is a real nasty bug.

Intel's statement is a nice piece of work.  They are trying to say that other CPU vendors have the same issue.  ARM, for it's credit, has stated that some of their CPUs are affected by this bug as well.  AMD, which has been pointed out on here before, is immune to this type of attack, although Intel is implying that they are not immune.  So it looks to me like Intel is trying to say everyone has this flaw, even when some do not, so they don't stink so bad.


----------



## Maelstorm (Jan 4, 2018)

Snurg said:


> So my impression for now:
> 1. scan the virtual address space with increments of about half kernel size.
> 2. as soon as mapped memory has been found, find its start/end addresses
> 3. Finally walk through the kernel memory and retrieve the interesting things (accounts, certs, ...)



In effect, `chmod +r /dev/kmem` is just as effective.


----------



## Avernar (Jan 4, 2018)

Maelstorm said:


> although Intel is implying that they are not immune


AMD is vulnerable to only 1 of the 3 attacks.  The one that needs the PTI fix, which is the one with the big performance hit, is not it.  And so far only FX and the APU chips are shown to be vulnerable to that one.

https://mobile.twitter.com/ryanshrout/status/948683677244018689

Number 3 is the one that required the PTI fix.  But yeah, Intel is implying that AMD will be hit just a bad which is far from the truth.


----------



## rigoletto@ (Jan 4, 2018)

Fortunately I have a K6 sitting somewhere.


----------



## Snurg (Jan 4, 2018)

Maelstorm said:


> In effect, `chmod +r /dev/kmem` is just as effective.


I wonder whether Microsoft will make an exception and issue a security fix for discontinued Windows XP and 7, as they did when there was this thing which allowed to take over Windows PCs with a single IP packet.

Regarding the Intel press release, they are talking of an embargo end _next week_.
I wonder whether that was their original plan, as several posts like this Xen advisory page indicate that the embargo will end _today at midnight_.
As I do not believe that, for example, the Xen team, would break one-sidedly the embargo appointment, I conclude that originally Jan 4th was the planned date to lift the embargo.

Thus I get the impression that* Intel, for some reason, apparently decided to postpone the embargo lift.*
But, why?

Attempt to save face by getting some more time to calm waves until the broad public has lost the interest?
*Or, has it turned out that the thing is in fact even worse?*
(Just had to think of the Fukushima nuclear catastrophe, where Tepco admitted the obvious only months later, that the cores have molten down?


----------



## rigoletto@ (Jan 4, 2018)

Snurg 

I feel it is more like to find a way to also deep imply AMD in the thing.


----------



## rigoletto@ (Jan 4, 2018)

Using Meltdown to steal passwords in real time.


----------



## Snurg (Jan 4, 2018)

lebarondemerde said:


> I feel it is more like to find a way to also deep imply AMD in the thing.


I have a similiar feeling.
What wonders me is that there is no official AMD press release yet.
That might be related to the fact that the Google project zero team identified a bounds checking flaw (thanks Avernar for the link) in the AMD processors (which can be fixed, with quasi zero impact on performance).
The only AMD message was from an AMD employee. And AMD always could say, his statement was not official and not authorized. Thus AMD is not "fully clean", either.

Admittedly, compared to the severity of what they found on Intel processors, this AMD bug is (almost) nothing.
But, will the broad public understand that?

Edit: At the end of the ProjectZero report there is a link provided by AMD. This is official, but quiet... no press release or such.


----------



## Snurg (Jan 4, 2018)

Maelstorm said:


> They can even use this attack to read memory from a different process, breaking process isolation.  So yeah, this is a real nasty bug.


Demonstrated here using the Firefox password wallet as example. (another tweet from the guy lebarondemerde linked to)


----------



## rigoletto@ (Jan 4, 2018)

Interestingly, RHEL does imply IBM in the thing too, in HERE.

Btw, #freebsd and #freebsd-social are super hot on the subject all day long.


----------



## ulzeraj (Jan 4, 2018)

Apparently Apple has it fixed since December:

https://twitter.com/aionescu/status/948609809540046849


----------



## ralphbsz (Jan 4, 2018)

So the bug is reported to Intel, AMD and ARM in the summer.  Apple fixes it in December; no other OSes have fixes yet.  It becomes public knowledge on January 2nd, and on January 3rd Intel claims that (a) it is not a problem anyway, and (b) AMD and ARM have the same problem.  There are no known exploits of it.

That reminds me of two jokes.  The first one is from the 80s: If in January an American scientist invents a new semiconductor device in Silicon Valley, then in February the Pravda will publish that it was already invented 30 years ago by Comrade Markov; in March citizens committee's form in Germany to protest the environmental impact of the new technology, and in April the first products based on the idea are shipped by the Japanese.

Second one: A guy is in court, being sued to pay damages for having broken an earthenware jug he had borrowed.  His defenses are threefold: First, that the jug isn't actually broken at all.  Second, that the jug was already broken when he borrowed it.  Third, that it wasn't his fault that the jug fell down and broke.


----------



## Avernar (Jan 4, 2018)

Snurg said:


> no official AMD press release yet


Strange they didn't update their site but they did release a statement: https://www.cnbc.com/2018/01/03/amd-rebukes-intel-says-flaw-poses-near-zero-risk-to-its-chips.html


----------



## rigoletto@ (Jan 4, 2018)

*We translated Intel's crap attempt to spin its way out of CPU security bug PR nightmare*


----------



## Snurg (Jan 4, 2018)

Now the Xen team released a report.
A few quotes:


> This vulnerability was originally scheduled to be made public on 9
> January.  It was accelerated at the request of the discloser due to
> one of the issues being made public.





> We believe that ARM is affected, but unfortunately due to the
> accelerated schedule, we haven't been able to get concrete input from
> ARM.  We are asking ARM and will publish more information when it is
> available.


----------



## Handsome Jack (Jan 4, 2018)

It seems fixed in Arch Linux ...


----------



## ShelLuser (Jan 4, 2018)

Don't know if you already saw this article but AMD and Arm also seem to be affected, according to El Reg of course but they're usually right about these things.


----------



## ronaldlees (Jan 4, 2018)

So, the Pi2 v1.1 has the A7, which was NOT on the list that was published yesterday.  The Pi3 has the A53 (also not on the list).  I guess I'm doing OK with the Pi2 boards and the Odroid XU4 boards, (8 cores: _4 cores are A15 (on list)_, _4_ _cores are A7 (not on list)_).  I've turned the four big cores off, since for net browsing they aren't needed.  It looks like my C1 boards are OK as A5s are not on the list.

Edit: _Now the ARM affected list is active:_

https://developer.arm.com/support/security-update

I'm reading various places that there are two main gaffs - "meltdown" and "spectre", with spectre being less immediately worrisome but harder to fix.   A small number of ARM cores were said to be susceptible to spectre. Apparently only the Cortex A75 is susceptible to meltdown.  A note on the linked page seems to indicate they're not very worried about the A15, but it's not clear to me. We are looking at the early reports, so this could all be wrong.  My other machines are all AMD.  I stopped using Intel a long time ago.  Happy for that.


----------



## rigoletto@ (Jan 4, 2018)

*Azure VMs borked following Meltdown patch, er, meltdown*


----------



## MarcoB (Jan 4, 2018)

ShelLuser said:


> Don't know if you already saw this article but AMD and Arm also seem to be affected, according to El Reg of course but they're usually right about these things.


Afaik in general the Intels are affected by the Meltdown bug and all cpu's are affected by the Spectre bug. There is also a list on the Intel website with the unfortunate cpu's:
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr
Seems that my machine is too old. But I'm still not 100% sure though.


----------



## teo (Jan 4, 2018)

In FreeBSD you can check the vulnerability of holes of security in Intel processors?


----------



## CyberCr33p (Jan 4, 2018)

https://forums.freebsd.org/threads/63955/


----------



## end222 (Jan 5, 2018)

Maybe it is a silly question but there is so much information regarding this topic and it was quite unclear.

What does the fix released for other OSs solve? I mean only Meltdown or both Meltdown and Spectre? Because I have read that Spectre could be harder to patch


----------



## ronaldlees (Jan 5, 2018)

Apparently, the thinking is that Spectre requires a hardware change on most platforms to fix - so no patch.  Meltdown can be patched.  This is the stuff that's being put out there.  Interestingly; the link in my last post shows a Spectre patch on the page, so I'm confused.


----------



## MarcoB (Jan 5, 2018)

The solution for now is "kernel page table isolation", but that only works against Meltdown. And that is what all os's are implementing now. Drawback of this patch is that it probably makes the os slower. For Spectre isn't a solution yet.

The only real solution is swap the chip for one that doesn't have the bugs.

Note that what's also confusing is that there are multiple teams that investigated the same bugs at the same time. But I think the two sites where it all comes together are:
- https://googleprojectzero.blogspot.nl/2018/01/reading-privileged-memory-with-side.html
- https://meltdownattack.com/


----------



## rigoletto@ (Jan 5, 2018)

*Retpoline: a software construct for preventing branch-target-injection*


----------



## ronaldlees (Jan 5, 2018)

lebarondemerde said:


> *Retpoline: a software construct for preventing branch-target-injection*



  A software fix for spectre: via compiler re-do - that clears up the confusion.


----------



## robert1307 (Jan 5, 2018)

From FreeBSD News Flash:
*4 January:* About the Meltdown and Spectre attacks: FreeBSD was made aware of the problems in late December 2017. We're working with CPU vendors and the published papers on these attacks to mitigate them on FreeBSD. Due to the fundamental nature of the attacks, no estimate is yet available for the publication date of patches.

Two questions:
- why it was known to other OS vendors in July and FreeBSD made aware in late December?
- can FreeBSD just copy the technique went into Linux kernel a while ago? Do they differ a lot in this subject?


----------



## ralphbsz (Jan 5, 2018)

robert1307 said:


> - why it was known to other OS vendors in July and FreeBSD made aware in late December?


How much money do Intel (and AMD) make from FreeBSD?  How many FreeBSD (or *BSD in general) developers does Intel have on staff?  I think the answer is: a little bit, and zero.  For Linux the answer is: many billions of $, and thousands.  That in and of itself is the core of the answer to your question.

The other issue is this: Since Intel (and RedHat and Microsoft and HP and IBM and Oracle and ... you name it) have thousands of Linux developers on their staff, and since those developers are either under normal trade secret protection or are willing to sign NDAs, the information about bugs like that is easier to distribute to them, without lawyers making a mess of things.  The extreme example of this is OpenBSD: No OpenBSD will ever sign an NDA (that's explicitly verboten by Theo), therefore OpenBSD developers will never get information about touchy subjects until it is out in public.  This is both good and bad; in the current situation it is bad for the development schedule of a fix.



> - can FreeBSD just copy the technique went into Linux kernel a while ago? Do they differ a lot in this subject?


They are very different.  The general idea can be copied, but the implementation has to be wholly separate.

By the way, I feel much more comfortable and safe running a well-managed FreeBSD system that is not fixed against Meltdown/Spectre, then running a Linux system that has been secured against them, but is badly managed (most Linux sytems are, to some extent because Linux has become so complex and byzantine that it is hard to manage cleanly and well, see the discussions about systemd being a mystery to most people).  That would be even more true for OpenBSD (alas, I no longer user OpenBSD, although not for reasons that should be interpreted as a criticism of OpenBSD).  Here's why: Both these bugs are fundamentally a door to privilege escalation: Once an attacker is already running programs on your computer (in user mode), they can get into kernel mode (or at least read kernel mode memory).  But if only trustworthy people even run programs on my computer, then it doesn't matter much that those trustworthy users could do nasty things, since by design they are trustworthy.  And I think that the *BSD systems are much less vulnerable to malware, and to unauthorized access.


----------



## Snurg (Jan 5, 2018)

ralphbsz said:


> But if only trustworthy people even run programs on my computer


I am not sure that I'd trust all the javascripts and web workers that run on my browsers.
There will be hectic activity in the scripter scene to make 1-day exploits, I guess.

Maybe it's not overly paranoid to at least block ads, avoid porn sites and the like until we got our fsckwit pendant.


----------



## ralphbsz (Jan 5, 2018)

Ah, good point.  My FreeBSD machine is only a server, has no user interface (console in text mode doesn't count), and never browses the web.


----------



## Maelstorm (Jan 5, 2018)

robert1307 said:


> From FreeBSD News Flash:
> *4 January:* About the Meltdown and Spectre attacks: FreeBSD was made aware of the problems in late December 2017. We're working with CPU vendors and the published papers on these attacks to mitigate them on FreeBSD. Due to the fundamental nature of the attacks, no estimate is yet available for the publication date of patches.



I guess that I am fortunate to be running AMD on my Windows system and both of my FreeBSD systems.  My OpenBSD system is not vulnerable to any of these exploits because it's a SPARC machine.  Come to think of it, the two firewall machines are also AMD.  I just hope that the *BSD developers do what was done in Linux...which is to check the CPU vendor before applying the fix.


----------



## wattie (Jan 5, 2018)

FreeBSD is used on many shared hosting servers.


----------



## aribi (Jan 5, 2018)

How about this for a quick fix: All variants depend on accurate timing of events. Couldn't we just mung the clock so that microsecond timing is not accurate anymore?
Imagine just rounding the HPET to millisecond and adding an incrementing value to keep it going up. It would certainly break these attacks!
What else would break by this approach?


----------



## Snurg (Jan 5, 2018)

aribi said:


> just mung the clock so that microsecond timing is not accurate anymore?


I like this idea. It would break not only Meltdown, but Spectre, too.


----------



## MarcoB (Jan 5, 2018)

Maelstorm said:


> I guess that I am fortunate to be running AMD on my Windows system and both of my FreeBSD systems.  My OpenBSD system is not vulnerable to any of these exploits because it's a SPARC machine.  Come to think of it, the two firewall machines are also AMD.  I just hope that the *BSD developers do what was done in Linux...which is to check the CPU vendor before applying the fix.


Are you sure? All cpu's with branch prediction are vulnerable for the Spectre variant. I think most of the cpu's in the last 20 years or so have that.


----------



## ralphbsz (Jan 5, 2018)

aribi said:


> Couldn't we just mung the clock so that microsecond timing is not accurate anymore?


No, the timing used here is much more accurate than microsecond timing; it's the CPU's internal cycle counters.
And one can't just break the clock, because programs are capable of making their own clock.  They can for example have a separate thread that runs on a separate core, and which does nothing but regularly issue slow but steady operations (like long floating-point divides) that have predictable performance, and count how many get done.



> Imagine just rounding the HPET to millisecond and adding an incrementing value to keep it going up. It would certainly break these attacks!
> What else would break by this approach?


Good question.  Normal user-level code (things like awk, sed and grep, or analytics or data bases) don't measure timing of operations accurately, since they care to get work done, not so much how long the work takes.  There are certainly micro-benchmarks that measure timing to microsecond level; for example doing performance studies of disk drives needs to be that accurate when dealing with SSDs.    If those benchmarks average over long enough periods, they should be OK, since they operate on time differences, which eventually have to smooth out.  So people would do precision benchmarks would notice that their measurements have much more variance, but the long-term average is still right.

I know that there are programs that change their behavior based on performance measurements.  One example are big data bases, which measure how fast the disk subsystem is (both random and sequential) compared to memory accesses, and adjust their query optimization strategies based on that (whether to build temporary tables and temporary indices, and whether to process them random or sequential).  Another example are storage systems that track disk performance to call for preventive maintenance, and to steer workload to faster disks.  Deliberately breaking timing could theoretically disrupt these techniques, but I think people who write such high-precision measurement tools know how to guard against statistical fluctuations.


----------



## Snurg (Jan 5, 2018)

ralphbsz said:


> No, the timing used here is much more accurate than microsecond timing; it's the CPU's internal cycle counters.
> And one can't just break the clock, because programs are capable of making their own clock.


You are right. But, the access to the RDTSC (read time stamp counter) instruction can be disabled, so that an attempt to read that results in an privilege exception.
Does there exist an option to disallow this instruction in user mode?
And regarding alternatives, like a second thread on another cpu, I am not sure whether such will be exact and fine-grained enough to be used for Spectre. Aside of the difficulty to set that up such from inside a browser.



ralphbsz said:


> Deliberately breaking timing could theoretically disrupt these techniques


Hmm. The examples you listed are typical for servers. These usually don't have to execute untrusted foreign code like browsers.
Maybe it would be sufficient to reduce the granularity from, say, 1 to 3 microseconds, to make the high res time counter functions unsuitable for bug exploiting, without taking away more precision than necessary.


----------



## ralphbsz (Jan 5, 2018)

Snurg said:


> You are right. But, the access to the RDTSC (read time stamp counter) instruction can be disabled, so that an attempt to read that results in an privilege exception.
> Does there exist an option to disallow this instruction in user mode?


That might be possible (I don't know whether it is, haven't checked).  But I think it's impractical, because then one would have to fix every harmless application that uses this technique for measuring time.  And I'm sure that 99.9% of those uses (perhaps 100%) are not malicious.

But as you said, compromises might be possible.


----------



## Handsome Jack (Jan 5, 2018)

aribi said:


> How about this for a quick fix: All variants depend on accurate timing of events. Couldn't we just mung the clock so that microsecond timing is not accurate anymore?
> Imagine just rounding the HPET to millisecond and adding an incrementing value to keep it going up. It would certainly break these attacks!
> What else would break by this approach?


That is similar to Mozilla fix in Firefox 57.0.4 :


			
				mozilla said:
			
		

> Since this new class of attacks involves measuring precise time intervals, as a partial, short-term, mitigation we are disabling or reducing the precision of several time sources in Firefox. The precision of performance.now() has been reduced from 5μs to 20μs, and the SharedArrayBuffer feature has been disabled because it can be used to construct a high-resolution timer.
> SharedArrayBuffer is already disabled in Firefox 52 ESR


----------



## MarcoB (Jan 5, 2018)

Interesting explaination why the Raspberry Pi isn't vulnerable (and why others are):
https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/

In short: "The lack of speculation in the ARM1176, Cortex-A7, and Cortex-A53 cores used in Raspberry Pi render us immune to attacks of the sort."


----------



## Maxiu (Jan 5, 2018)

In my opinion someone should check facebook's script. I'm told few times (for block it) here on another account's.


----------



## Eric Pancoast (Jan 5, 2018)

Looks like the DragonFly guys have a potential mitigation for Meltdown:

https://www.dragonflydigest.com/2018/01/05/20672.html



> By now you’ve probably heard of the Meltdown/Spectre attacks.  (background rumors, technical note)  Matthew Dillon’s put together a Meltdown mitigation in DragonFly, done in four commits.
> 
> It’s turned off and on by the sysctl machdep.isolated_user_pmap – and defaults to on for Intel CPUs.  Buildworld tests show about a 4-5% performance hit, but that’s only one form of activity, measured, so there will surely be other effects.
> 
> Note that Spectre is not mitigated by this commit series, and as I understand it, cannot be realistically fixed in software.


----------



## _martin (Jan 5, 2018)

Personally what I'm looking for is to see if and if not why Itanium processors are not affected (spectre). In ideal world in example as shown on RPI. 

Btw. here's the official statement of IBM on ppc processors: https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/

I understand why Itanium processors are not affected by meltdown, but I'm not sure about spectre. From little I know it could be due to EPIC and the way vliw (very long instruction word) is executed -- there's no room for such side channel. But with the focus on all other CPUs it's a bit disturbing there is no additional information regarding this attack for Itanium processors.


----------



## Deleted member 30996 (Jan 6, 2018)

Intel facing multiple class action suits over chip security flaw

All my machines but one use an Intel processor. It has an AMD Triple Core with 4GB RAM and I use it sometime anyway.

I hate the thought of my Thinkpads taking a big performance hit. They are totally acceptable in performance now, but could end up a pain to use.

Now I'm emotional distressed and feeling anxious... I better get in on that lawsuit.


----------



## Eric A. Borisch (Jan 6, 2018)

_martin said:


> Personally what I'm looking for is to see if and if not why Itanium processors are not affected (spectre). In ideal world in example as shown on RPI.
> 
> Btw. here's the official statement of IBM on ppc processors: https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/
> 
> I understand why Itanium processors are not affected by meltdown, but I'm not sure about spectre. From little I know it could be due to EPIC and the way vliw (very long instruction word) is executed -- there's no room for such side channel. But with the focus on all other CPUs it's a bit disturbing there is no additional information regarding this attack for Itanium processors.



I believe for the same reason as Raspberry Pis are not: no out-of-order execution. If I understand correctly, all three exploits rely on speculative fetch/jump/execution operations which are eventually rolled back (but not their side effects—cache loads) when bounds / access checks complete.


----------



## Datapanic (Jan 6, 2018)

On the lighter side, I think I'll be able to afford that Intel i7 very soon!

On the darker side, I've been on vacation time all week!


----------



## Maelstorm (Jan 6, 2018)

I've read somewhere that Intel knew about this 15 years ago and did nothing about it.  However, I find that highly dubious.  Intel's chips have gone through several redesigns over the years.  If they knew about this 15 years ago, then why didn't they address it during the design phase?

I'll tell you why, because it's bogus.  I believe they found out about this back in July when it was first reported to them.  The next generation of CPUs will not be vulnerable to either one.  Further evidence indicates that all CPUs that use branch predictors with out of order and speculative execution are vulnerable to spectre.  Once again, nobody saw this coming.  And now Intel is getting sued over it.  Is it fair? Is it just?  No, it's not, but it is going to be expensive to fix.

IANAL, but my defense would be this: Nobody saw this coming, nobody knew about it until it was reported.  We are all human beings.  With that said, we cannot predict the future.  Security is reactionary with regards to bugs.  When these designs were first implemented, these types of attacks were not conceived of.

The Meltdown bug is pointing straight at Intel.  But the Spectre bug however, is going to need a rethink of the basic CPU design which is going to take longer.  How long did it take for Intel to roll out new silicon when Intel was notified about the F00F bug in the Pentium, or the FPU bug, or that one in 2001, or any of the other bugs?


----------



## Snurg (Jan 6, 2018)

Maelstorm said:


> The Meltdown bug is pointing straight at Intel.


There are people who argue that the motivation to allow deficiencies in hardware security could have been to gain unfair advantage over competitors.
And the basic problem was known for decades already from the mainframe sector experience.

So I don't think a company like Intel can get away with pretending they knew nothing.
With their doing they damaged the whole industry, the whole human community.
They pressured competitors to cut at hardware security, only to be able to compete with a cheater.

Imho Intel should pay dearly for that, maybe fined to pay a few dozen billions to charities.
But I am no legalese expert. And those will determine the outcome.

For my part, I hope this damages Intel in a way that permanently lowers its market share, increasing competition and innovation.


----------



## tsarya (Jan 6, 2018)

Great thread guys, I really enjoy reading it!

I am not a computer scientist so for me it is hard to understand the full impact of these security holes.

Has anyone read anything about the impact on VMs?
My questions is if you could read kernel memory on Intel machines (OS on bare metal) exploiting these flaws, how about if you exploit the flaws within a VM, would one be able to read beyond what's assigned as memory address space to the VM and say one could read memory from the VM host or another VM?


----------



## _martin (Jan 6, 2018)

Eric A. Borisch said:


> I believe for the same reason as Raspberry Pis are not: no out-of-order execution. If I understand correctly, all three exploits rely on speculative fetch/jump/execution operations which are eventually rolled back (but not their side effects—cache loads) when bounds / access checks complete.


Meltdown is abusing out-of-order execution and tries to win a race so those instructions are executed. That instruction is using one byte of read memory you don't have access to as an index to your data. By measuring your access time to all the data you can say which byte it was (addr in cache already).

There's no out-of-order execution on Itanium, it is EPIC (explicitly parallel instruction computing). There are speculative loads, there are special registers just for that.
So spectre is maybe possible. I didn't read the paper on it yet, though I don't have that deep understanding of Itanium processors (did write only handful of assembly code for this CPU) to say it is or isn't possible.


----------



## teo (Jan 6, 2018)

Taken from fragments of the holes vulnerability scandal that massively affects Intel processors,  stealthy surveillance and total control?  

ME firmware version 7.0 on PCHs with 2nd Generation Intel Core i3/i5/i7 (Sandy Bridge) CPUs replaces PAVP with a similar DRM application called “Intel Insider”. Like the AMT application, these DRM applications, which in themselves are defective by design, demonstrate the omnipotent capabilities of the ME: this hardware and its proprietary firmware can access and control everything that is in RAM and even everything that is shown on the screen.

The Intel Management Engine with its proprietary firmware has complete access to and control over the PC: it can power on or shut down the PC, read all open files, examine all running applications, track all keys pressed and mouse movements, and even capture or display images on the screen. And it has a network interface that is demonstrably insecure, which can allow an attacker on the network to inject rootkits that completely compromise the PC and can report to the attacker all activities performed on the PC. It is a threat to freedom, security, and privacy that can’t be ignored.

Before version 6.0 (that is, on systems from 2008/2009 and earlier), the ME can be disabled by setting a couple of values in the SPI flash memory. The ME firmware can then be removed entirely from the flash memory space. libreboot does this on the Intel 4 Series systems that it supports, such as the Libreboot X200 and Libreboot T400. ME firmware versions 6.0 and later, which are found on all systems with an Intel Core i3/i5/i7 CPU and a PCH, include “ME Ignition” firmware that performs some hardware initialization and power management. If the ME’s boot ROM does not find in the SPI flash memory an ME firmware manifest with a valid Intel signature, the whole PC will shut down after 30 minutes.

Due to the signature verification, developing free replacement firmware for the ME is basically impossible. The only entity capable of replacing the ME firmware is Intel. As previously stated, the ME firmware includes proprietary code licensed from third parties, so Intel couldn’t release the source code even if they wanted to. And even if they developed completely new ME firmware without third-party proprietary code and released its source code, the ME’s boot ROM would reject any modified firmware that isn’t signed by Intel. Thus, the ME firmware is both hopelessly proprietary and “tivoized”.
On all recent Intel systems, coreboot support has revolved around integrating a blob (for each system) called the FSP (firmware support package), which handles all of the hardware initialization, including memory and CPU initialization. Reverse engineering and replacing this blob is almost impossible, due to how complex it is. Even for the most skilled developer, it would take years to replace. Intel distributes this blob to firmware developers, without source.

Since the FSP is responsible for the early hardware initialization, that means it also handles SMM (System Management Mode). This is a special mode that operates below the operating system level. It’s possible that rootkits could be implemented there, which could perform a number of attacks on the user (the list is endless). Any Intel system that has the proprietary FSP blob cannot be trusted at all. In fact, several SMM rootkits have been demonstrated in the wild (use a search engine to find them).


In summary, the Intel Management Engine and its applications are a backdoor with total access to and control over the rest of the PC. The ME is a threat to freedom, security, and privacy, and the libreboot project strongly recommends avoiding it entirely. Since recent versions of it can’t be removed, this means avoiding all recent generations of Intel hardware.  Link for more information:

https://libreboot.org/faq.html#intel


----------



## ralphbsz (Jan 6, 2018)

tsarya said:


> My questions is if you could read kernel memory on Intel machines (OS on bare metal) exploiting these flaws, how about if you exploit the flaws within a VM, would one be able to read beyond what's assigned as memory address space to the VM and say one could read memory from the VM host or another VM?


Good question.  With Meltdown (I have not thought through Spectre), a non-privileged user process can read all memory that is mapped, whether they have access privileges or not (albeit very slowly).  Traditionally, all kernel memory remains mapped, but marked as not accessible.  And traditionally (in a non-VM environment), all hardware memory is mapped in the kernel.

And therein also lies the solution to Meltdown: Don't map kernel memory in user processes; this is fundamentally what the KAISER-style patches do (I know KAISER itself is obsolete, I can't remember all the other acronyms).

Now with a hypervisor in the middle, the question is: Does the kernel that run in the hypervisor map all hardware memory (even that which is assigned to other OS instances), or does it only map all "virtual hardware" memory that is assigned to this instance?  I don't know the answer, and it probably depends on which hypervisor you are using (Xen, VMware, ...).  My educated guess is that it is not mapped, and here is why: the memory layout in virtualized memory is probably the same for all instances, and having multiple instances mapped would make that harder to manage.  But I'm not at all sure.

And I'm sure the answer will change very quickly, in reaction to this mess.  While in theory fixing the local instance OS to not have these vulnerabilities should be sufficient, probably the VM vendors will want to put another layer of defense around that at their level.


----------



## ralphbsz (Jan 6, 2018)

Can someone remove teo's post?  I have don't know whether his rant is technically correct or not; it can't be completely correct, since in real-world operations computer administration requires a full-authority "backdoor" that can access everything in the hardware (in particular take over control if the installed OS is misbehaving).  But it is completely off-topic in this thread.  Thank you!


----------



## Snurg (Jan 6, 2018)

ralphbsz I do not think it is off-topic, as this topic is about Intel bugs.

There is indeed a big problem with the IME, and not for the first time.
2016 there was a severe bug discovered that caused manufacturers like HP to issue firmware updates for all their affected computers they made the last decade (!), including for long-discontinued models.
The reason was that *user programs can easily take over control of the IME*.
*Under particular circumstances IME makes it even possible to take over control remotely, circumventing the OS working on the computer!*

See this Intel security advisory, last revieved on Dec 26, 2017.
There they offer downloading a program which shows you whether your hardware is affected and needs a firmware update.

More background here, for example.


----------



## Datapanic (Jan 6, 2018)

> Has anyone read anything about the impact on VMs?



VMware has issued a statement and released patches here: https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html


----------



## Deleted member 30996 (Jan 6, 2018)

That Intel Management Engine issue is sooo 2017. They already found out a way to defend against that:

Now you, too, can disable Intel ME 'backdoor' thanks to the NSA


----------



## wattie (Jan 6, 2018)

https://www.epicgames.com/fortnite/forums/news/announcements/132642-epic-services-stability-update


----------



## Snurg (Jan 6, 2018)

Thanks wattie!
Your link includes one of the first revelations how the impact on the CPU loads has been grossly downplayed by Intel.
The CPU utilization statistcs chart speaks for itself.




This chart shows the CPU load change after application of the security updates.
As you can see, server CPU performance dropped not _by_ the announced maximum of 30%, but _down to_ almost 30% of the performance before the update.


----------



## rigoletto@ (Jan 7, 2018)

https://it.slashdot.org/story/18/01/06/014226/linus-torvalds-says-intel-needs-to-admit-it-h


----------



## Maelstorm (Jan 7, 2018)

The issue with Spectre is that a malicious program can read its own process memory.  Normally, that's not an issue for regular programs because they have to be able to read their process memory in order to function.  Where it becomes an issue is virtual machines.  The program running under the hypervisor runs in the same process space as the hypervisor itself (same PID, memory, etc...).  A program running under a VM can read memory belonging to the hypervisor.  A attacker can use this information to break out of the VM, and possibly compromise the machine.  So Spectre is an information leak bug which can lead to a privilege escalation depending on the specifics of the hypervisor.

This affects any code that runs in a virtual environment.  A Java application running in a web browser for instance.  There have been numerous security issues relating to Java in this regard.  Also javascript in web browsers runs in a virtual environment.  A malicious javascript program can compromise the browser's process and read passwords, crypto keys, etc....


----------



## Deleted member 9563 (Jan 7, 2018)

> Elsewhere Linus told ZDNet that "there's no one number" for the performance drop users will experience after patches. "It will depend on your hardware and on your load. I think 5 percent for a load with a noticeable kernel component (e.g. a database) is roughly in the right ballpark. But if you do micro-benchmarks that really try to stress it, you might see double-digit performance degradation. A number of loads will spend almost all their time in user space, and not see much of an impact at all."



So yeah, a lot of us desktop users might not end up being bothered a lot about the new patches.

That said,  I just spent an hour trying to diagnose my VPN problem because my little brain had forgotten that I need to rewrite an iptables rule after a reboot. This, because that VPS has been solid for two years and suddenly got rebooted to accommodate the new patch. (and yes, I even got a warning email) /sigh


----------



## Eric Pancoast (Jan 7, 2018)

Initial performance details on the DragonFlyBSD Meltdown fix:

DragonFlyBSD's Meltdown Fix Causing More Slowdowns Than Linux

Also, NetBSD gets its first commits (seems to be Meltdown only as well):


> Maxime Villard is working hard tackling recent CPU bugs (still incomplete), including improved hotpatch support to minimize the performance impact for unaffected CPUs


https://twitter.com/netbsd/status/950050623260712962


----------



## macondo (Jan 8, 2018)

https://www.itwire.com/security/813...losure-incredibly-bad-openbsd-s-de-raadt.html


----------



## SirDice (Jan 8, 2018)

(thread merged with existing thread about Meltdown/Spectre)


----------



## rigoletto@ (Jan 8, 2018)

LoL Microsoft.


----------



## Eric A. Borisch (Jan 8, 2018)

For reference:

https://lists.freebsd.org/pipermail/freebsd-security/2018-January/009719.html

Edit: and https://reviews.freebsd.org/D13797 (linked to from the above message.)

Edit 2: Fixed link


----------



## kkaos (Jan 8, 2018)

Eric A. Borisch said:


> For reference:
> 
> https://lists.freebsd.org/pipermail/freebsd-security/2018-January/009719.html
> 
> Edit: and https://reviews.freebsd.org/D13797 (linked to from the above message.)



Thanks, Eric.  I was wondering how the FreeBSD fix was going.  By the way, the link to D13797 mistakenly includes a period in the mailing list post so here is the correct link excluding the period:  https://reviews.freebsd.org/D13797.


----------



## Eric Pancoast (Jan 8, 2018)

More DragonFlyBSD updates related to Meltdown:



> More Meltdown fixes
> 
> If you’re on the bleeding edge of DragonFly and already updated for Meltdown fixes, there’s a few more commits you’ll want to get.
> 
> Matthew Dillon wrote a summary of the current status, noting there’s not much you can do for Spectre beyond new hardware.   There is an update to the “defensive browser setup” plan for DragonFly (using –site-per-process) that can help at least with Javascript versions of Spectre.



I've seen Chromium's experimental "Site Isolation" feature mentioned multiple times now with regard to helping address some Spectre exploits via Javascript:
https://www.chromium.org/Home/chromium-security/site-isolation

I think we've already seen mentions in this thread of the latest Firefox releases addressing some aspects of Spectre, but since it's in context:
https://www.mozilla.org/en-US/security/advisories/mfsa2018-01/


----------



## gofer_touch (Jan 8, 2018)

Is it only DragonFly that has a fix currently?

https://www.reddit.com/r/freebsd/co...ade_aware_of_meltdown_and_spectre_in/ds9tf3s/

Nothing yet from Net or Open either?


----------



## Maxiu (Jan 8, 2018)

Google sucessfully applying patches. I hear if google Inc using FreeBSD as a system for hi's server... Apple is still Unix and it patching own system too. Why FreeBSD do not have a patches yet? Who know.... But FreeBSD after this patch will be back to throne as king of security, and way for fully anonimity, far away from Inc like a FB and Youtube. Oh I'm sorry.


----------



## Eric Pancoast (Jan 9, 2018)

gofer_touch said:


> Is it only DragonFly that has a fix currently?
> 
> https://www.reddit.com/r/freebsd/co...ade_aware_of_meltdown_and_spectre_in/ds9tf3s/
> 
> Nothing yet from Net or Open either?



Seems like DragonFlyBSD is the only flavor of FreeBSD that has patches for Meltdown at this time.

We saw a couple of patches from NetBSD for Meltdown as well:
https://twitter.com/netbsd/status/950050623260712962

Update: Eric also mentioned a patch for FreeBSD is in review:


Eric A. Borisch said:


> For reference:
> 
> https://lists.freebsd.org/pipermail/freebsd-security/2018-January/009719.html
> 
> ...



---

Also,I thought this was an interesting description of the vulnerability and why Raspberry Pi hardware is not vulnerable:


MarcoB said:


> Interesting explaination why the Raspberry Pi isn't vulnerable (and why others are):
> https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/
> 
> In short: "The lack of speculation in the ARM1176, Cortex-A7, and Cortex-A53 cores used in Raspberry Pi render us immune to attacks of the sort."


----------



## mefizto (Jan 9, 2018)

Greetings all,

this may be a naive question, but I am no computer science expert.

As I understand it, an illicit software still must be installed to take advantage of the bugs, er, features.  So, if an individual is careful  about the attack channels, _i.e._, does not visit shady web-sites, has java-script turned off, is careful with opening strange files and attachments, _etc_., how big the risk really is?

Or am I completely missing an important concept?

Kindest regards,

M


----------



## MarcoB (Jan 9, 2018)

mefizto said:


> Greetings all,
> 
> this may be a naive question, but I am no computer science expert.
> 
> ...


I think you are right. But:
- Most computer users do not care for security and do not use ad/script blockers, and visit every site they want;
- The Meltdown/Spectre bugs are hardware bugs, and os's now need to try to patch things. Which is actually impossible because the only real solution is to remove the processor, and it has a serious performance impact.


----------



## ralphbsz (Jan 9, 2018)

mefizto said:


> As I understand it, an illicit software still must be installed to take advantage of the bugs, er, features.  So, if an individual is careful  about the attack channels, _i.e._, does not visit shady web-sites, has java-script turned off, is careful with opening strange files and attachments, _etc_., how big the risk really is?


Absolutely correct.  To exploit these bugs, an exploit must be running on your machine.  The best protection against these bugs is to only allow trusted users to access your machine (which is easy for a single-user desktop/laptop, a bit harder for a shared server), and then ask those users to only install or run trusted software.

If you run a server without a GUI, this is reasonably easy to accomplish.

And as you point out, the big gap in this is the web browser.  We have gotten into the bad habit of allowing any arbitrary Java and Javascript to run in our browser windows.  And in their implementation, these languages allow people to perform arbitrary memory accesses and arbitrary instructions.  That wasn't always the case; if you remember when Java first came out, one of the important ideas behind it was to "sandbox" code that ran in browsers or in applets, so it could do no harm.  But in those days, "harm" was defined differently: code could not print, not open arbitrary files, and such.


----------



## Deleted member 30996 (Jan 9, 2018)

ralphbsz said:


> And as you point out, the big gap in this is the web browser.  We have gotten into the bad habit of allowing any arbitrary Java and Javascript to run in our browser windows.  And in their implementation, these languages allow people to perform arbitrary memory accesses and arbitrary instructions.



One more reason to use the NoScript extension and only allow select scripts to run.


----------



## MarcoB (Jan 9, 2018)

Somebody posted some interesting links on daemonforums.org:
http://daemonforums.org/showpost.php?p=63733&postcount=19


----------



## rufwoof (Jan 9, 2018)

Trihexagonal said:


> One more reason to use the NoScript extension and only allow select scripts to run.


Common/widespread poor web page design nowadays more often leaves no option other than 1. enable scripts or 2. search/use elsewhere. The new version of NoScript for Firefox 57.0.4 (that is patched for exploits) is also pretty poor IMO. 

I dual boot. One system treated as though it were a public PC despite being sole user installed to the first partition. Data stored on the second partition (I use ext3 format as that can be mounted as though ext4 by Linux, and/or as ext2 by BSD) with good quality disconnected backups of that data. Third partition BSD, secure, only used for accessing known/trusted web sites (online banking etc.). Thinking about setting up a separate box entirely for that, to avoid reboots, but I'm not really a regular financial transactions type user, more a case of once/month or so paying the bills type user and it takes just 10 mins or so to freshly install the third partition (latest factory fresh/pristine snapshot, with latest factory fresh copy of browser).

Hint to businesses, if you want to increase your online revenues ensure that your web page developers/providers include non-javascript versions.


----------



## MarcoB (Jan 9, 2018)

rufwoof said:


> Common/widespread poor web page design nowadays more often leaves no option other than 1. enable scripts or 2. search/use elsewhere. The new version of NoScript for Firefox 57.0.4 (that is patched for exploits) is also pretty poor IMO.


uMatrix is really nice.


----------



## Deleted member 45312 (Jan 9, 2018)

uBlock Origin with defensive settings: all is blocked except what I selectively allow.


----------



## rufwoof (Jan 9, 2018)

MarcoB said:


> uMatrix is really nice.


Thanks. I'll keep that in mind. Still using firefox-esr 52.5.2 as my general use browser in which NoScript works great, and on my BSD boot I don't install any addons anyway.


----------



## rufwoof (Jan 9, 2018)

dlegrand said:


> uBlock Origin with defensive settings: all is blocked except what I selectively allow.


How do you set defensive settings? Generally I have a anti add /etc/hosts file (lots of entries), I also have NoScript, and Ublock Origin installed, but I've never changed it from its default settings (seems to work fine with that, but if there is a more defensive option I'd like to try that out). I have looked through the dashboard options, but didn't see anything obvious about changing the settings to being even more secure.


----------



## Deleted member 45312 (Jan 9, 2018)

In the parameters tab, you can select advanced user features to get extra column for global rules. Click on the box 'All' in red to block all.


----------



## ronaldlees (Jan 9, 2018)

https://www.commitstrip.com/wp-cont...Intel-Meltdown-Spectre-english650-finalv2.jpg


----------



## Snurg (Jan 10, 2018)

According to German IT magazine golem.de Intel chieftain announced they will release microcode fixes for meltdown and spectre for processors up to 5 years old in less than a week.

I guess this step was motivated only by the threat of lawsuits, and the fear of being sentenced to refund 1/3 or more of the price of every processor still under warranty they do not fix, compensating for the performance loss and additional damage, like increased power consumption, service disruptions due to infrastructure getting overloaded. For example, the German laws would allow for such.

My Intel processors were released 5 1/2 yrs ago. I really hope that community increases pressure on Intel to release microcode fixes for older processors also.


----------



## Sensucht94 (Jan 10, 2018)

Gordon Tetlow, FreeBSD Security Team: *Response to Meltdown and Spectre*


----------



## xchris (Jan 10, 2018)

gofer_touch said:


> Nothing yet from Net or Open either?



Technically the NetBSD users can use the sysutils/intel-microcode-netbsd to update the latest cpu firmware from Intel.


----------



## Sensucht94 (Jan 10, 2018)

xchris said:


> Technically the NetBSD users can use the sysutils/intel-microcode-netbsd to update the latest cpu firmware from Intel.


Yes, confirmed, I've been layely looking for a security update on pkgsrc.se, and today found it had just been submitted  *sysutils/intel-microcode-netbsd*


> Log message: Update Intel microcode with newest version which, hopefully, has more fixes for Meltdown and Spectre vulnerabilites



On DragonflyBSD Matt Dillon  addressed Meltdown with patch:
*Intel user/kernel separation MMU bug fix part 4*
Benchmarks report with performance impact:
*Intel user/kernel separation MMU bug fix part 3*
and started implementing Spectre mitigations with patch:
*Implement spectre mitigations part 1
*
Anyway, it looks like FreeBSD's sysutils/devcpu-data has just received an update too, *Revision 458617*:


> Update Intel microcode to 20180108
> 
> MFH:        2018Q1



It should contain the latest firmware definitions, involving  (hopefully) a  partial security fix, as for NetBSD:  I didn't manage to find better reference anywhere else. Likely someone else here  is better informed


----------



## _martin (Jan 10, 2018)

Not sure if it was mentioned this already, but here's the microcode from Intel: https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?product=122139

What I'm confused about is -- what does the microcode fixes ? Does it mean OS doesn't need to be patched ?


----------



## Eric Pancoast (Jan 10, 2018)

Also, DragonFlyBSD note on microcode updates:



> *Microcode updates on DragonFly*
> 
> One side effect of Meltdown/Spectre are CPU microcode (firmware) updates.  For future needs: sysutils/devcpu-data is the port that has the updates for Intel, and cpucontrol(8) is the program you run on DragonFly to add them.
> 
> ...



Does anyone know if these microcode updates are the first stab at addressing Spectre Variant 2 that requires IBRS (Indirect Branch Restricted Speculation) to mitigate?

---



_martin said:


> Not sure if it was mentioned this already, but here's the microcode from Intel: https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?product=122139
> 
> What I'm confused about is -- what does the microcode fixes ? Does it mean OS doesn't need to be patched ?



My understanding is that there are 3 separate vulnerabilities to address:

1) Meltdown: Intel-only issue related to out-of-order execution.  Requires KPTI (Kernel page-table isolation) as an OS patch to mitigate.

2) Spectre: (has 2 Variants) Impacts all processors with branch prediction that perform speculative execution.

Variant 1: Requires compiler changes to mitigate.  We've seen some web browser updates to prevent exploitation via JavaScript.

Variant 2: Requires IBRS (Indirect Branch Restricted Speculation) and CPU microcode updates to mitigate.


----------



## Snurg (Jan 10, 2018)

I find it very interesting that Intel first didn't tell about offering microcode updates.
Apparently they decided to do so when they found out that in some jurisdictions this would even entitle customers to get full refund if they do not fix the processors to be in the specs they originally promised.


----------



## MarcoB (Jan 10, 2018)

My guess is that Intel is doing this only for legal reasons: to avoid paying damages for 20 years of faulty products. The posting on daemonforums.org with a link to https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f6536c91aaf7756857.pdf shows that these security problems are known at least since 1995.


----------



## ralphbsz (Jan 10, 2018)

And note that the Spectre "mitigation" is not a complete prevention; it just makes the the problem less likely to occur.  I think that a complete prevention of Spectre (both variants) will require major redesign of the CPUs itself (much more than a microcode fix can do), to always perform memory accessibility checking during speculative execution.  Fortunately, Spectre is not an easy exploit, so the current compromise with an imperfect mitigation is probably good enough.  And when I say "CPUs" above, I mean nearly all CPUs that perform speculative execution, not just Intel, nor just x86 instruction set CPUs like Intel and AMD.


----------



## MarcoB (Jan 10, 2018)

Intel has microcode data files made available for download (https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?product=873). Linux and Windows only of course. I wonder if it will ever be possible to install this on my Intel based machines.

Edit: ok just found out we have a utility in the portstree called sysutils/devcpu-data.


----------



## Snurg (Jan 10, 2018)

Mhh. Flashing stuff is fickle and can brick things.
Do you think it's safe just to take a LiveCD, just for installing the microcode?
Or is it better to install for example Debian base system on a spare HD?


----------



## MarcoB (Jan 10, 2018)

Yeah, I have my doubts too. Trying to find out now if this stuff is safe to use. Can't afford my computer getting hosed.


----------



## _martin (Jan 10, 2018)

Eric Pancoast said:


> Variant 2: Requires IBRS (Indirect Branch Restricted Speculation) and CPU microcode updates to mitigate.



It does make sense. Meltdown patches are easy(-ier) to understand, spectre one are confusing to me (a bit), updated microcode added to my confusion. 

Funny though as there's pressure on Intel but lots of people are forgetting to mention Itanium. It seems there is no problem there. So there's CPU where Intel did it right.


----------



## mefizto (Jan 10, 2018)

Hi MarcoB, ralphbsz,

thank you for your answers.

Kindest regards,

M


----------



## MarcoB (Jan 10, 2018)

Itanium is also in the list of the microcode update, so maybe it's for the Spectre variant?


----------



## Eric A. Borisch (Jan 10, 2018)

MarcoB said:


> Yeah, I have my doubts too. Trying to find out now if this stuff is safe to use. Can't afford my computer getting hosed.



It's not that hard, and it is documented in the FAQs:

https://www.freebsd.org/doc/en/books/faq/compatibility-processors.html#idp56139752

I wouldn't apply to a live system with VMs running, however. (Reboot, and let them apply before VMs are started, or stop VMs and then apply.)


----------



## MarcoB (Jan 10, 2018)

I know it's not hard to install, but what if it fails? What's the chance of your cpu's being broken?


----------



## Eric Pancoast (Jan 10, 2018)

_martin said:


> It does make sense. Meltdown patches are easy(-ier) to understand, spectre one are confusing to me (a bit), updated microcode added to my confusion.



I guess we'll never know exactly *how* the microcode update alters the processor's function to expose additional functionality to the kernel to achieve IBRS (https://lkml.org/lkml/2018/1/4/615).

Update: I think it's also worth reiterating that it seems the microcode update is not everything you need to protect against certain aspects of Spectre.  An OS kernel update is also required to make use of the microcode update.


----------



## _martin (Jan 10, 2018)

MarcoB said:


> Itanium is also in the list of the microcode update, so maybe it's for the Spectre variant?



That's actually a good catch! 

Today we were talking about the issue , I can't talk too much about it, but the oficial statement is - not affected. I was actually saying (and mentioned it even in this thread) that I have doubt about that unless there's something really different in the design (predicament regs, cache flush, etc..). 

This surprised me now ..


----------



## lyuts (Jan 10, 2018)

Snurg said:


> Do you think it's safe just to take a LiveCD, just for installing the microcode?



I don't think it is sufficient. My understanding is that microcode has to be updated on every boot.
sysutils/devcpu-data installs /usr/local/etc/rc.d/microcode_update that takes care of applying latest microcode on startup.


----------



## Eric Pancoast (Jan 10, 2018)

lyuts said:


> I don't think it is sufficient. My understanding is that microcode has to be updated on every boot.





Hornpipe2 said:


> Remember that this wears off on reboot, so if you want it to stick then you must enable the update at boot: edit rc.conf and add
> microcode_update_enable="YES"



According to this thread, the microcode itself is managed by the port, so I'd be careful about updates to that port introducing new microcode without you being fully aware.


----------



## Eric A. Borisch (Jan 10, 2018)

The microcode here needs to be re-applied on every reboot; it is not a permanent flash/burn/whatever of the CPU. With respect to who manages the port, the microcode updates themselves are encrypted by intel, so I'd think it highly unlikely that you can get a non-intel-blessed microcode update to apply itself, unless Intel accidentally releases the encryption key...

https://superuser.com/questions/1229317/can-intel-microcode-updates-be-rolled-back


----------



## Deleted member 30996 (Jan 10, 2018)

I built the sysutils/devcpu-data port and ran it with the proper line in etc/rc.conf on one of my Thinkpads with Intel Core2 Duo T7300 @ 2.00GHz.

During the boot cycle it showed:


```
Updating CPU Microcode...
Re-evaluation of CPU flags Failed
```
I get the same result running `# service microcode_update start`.

So evidently it didn't do anything, it is almost 10 years old,  but at least it didn't brick it cause I'm using it now.


----------



## Eric A. Borisch (Jan 10, 2018)

Trihexagonal said:


> I built the sysutils/devcpu-data port and ran it with the proper line in etc/rc.conf on one of my Thinkpads with Intel Core2 Duo T7300 @ 2.00GHz.
> 
> During the boot cycle it showed:
> 
> ...



`grep micro /var/log/messages` ?


----------



## Deleted member 30996 (Jan 11, 2018)

```
root@relentless:/ # grep micro /var/log/messages
Jan 10 17:05:46 relentless microcode_update: /usr/local/share/cpucontrol/m806fbBA.fw: updating cpu /dev/cpuctl0 from rev 0xb6 to rev 0xba... done.
Jan 10 17:05:46 relentless microcode_update: /usr/local/share/cpucontrol/m806fbBA.fw: updating cpu /dev/cpuctl1 from rev 0xb6 to rev 0xba... done.
```

I couldn't even tell it had applied them so if it took a performance hit I don't see it yet.

Edit: I tried it on my i386 box with Intel Dual Core T2060 @ 1.60GHz with the same


```
Updating CPU Microcode...
Re-evaluation of CPU flags Failed
```
message but don't get a return on `# grep micro /var/log/messages`.


----------



## Eric Pancoast (Jan 11, 2018)

Eric A. Borisch said:


> With respect to who manages the port, the microcode updates themselves are encrypted by intel, so I'd think it highly unlikely that you can get a non-intel-blessed microcode update to apply itself, unless Intel accidentally releases the encryption key...



This is a great point.

Also, for those who haven't necessarily had to worry about microcode updates for the security of their systems in the past, I think it makes sense to recognize that introducing this port, and the rc.conf option, could represent an unexpected source of instability.  Especially because if you ran "pkg upgrade" without a restart, you could be introducing new microcode updates into "/usr/local/share/cpucontrol/" that would only be loaded when the system is rebooted.

Of course, there should be a process for applying updates like these to "staging" environments and verifying the systems operate as expected before applying them to critical systems, but I think it's still worth mentioning.


----------



## Eric A. Borisch (Jan 11, 2018)

Eric Pancoast said:


> Of course, there should be a process for applying updates like these to "staging" environments and verifying the systems operate as expected before applying them to critical systems, but I think it's still worth mentioning.



Which is what ZFS + boot environments  excel at.

Easiest path:

`beadm create YYYYMMDD`
Do install/upgrade process
Reboot
If the upgraded system fails for some reason, reboot again, and choose your old BE from the loader menu. (Or use `beadm activate YYYYMMDD` if you can login.) Be sure to “activate” it when you are up such that it persists for the next reboot.

Edit: As with any snapshot of a running system, if you have services (e.g. a database) modifying critical on-disk state that is managed by beadm (under zroot/ROOT/*), you'll want to shut those down before performing the `beadm create`.


----------



## ralphbsz (Jan 11, 2018)

MarcoB said:


> Itanium is also in the list of the microcode update, so maybe it's for the Spectre variant?


Very strange.  I had heard a while ago that Itanium was immune from Meltdown and Spectre.  If you think about the Itanium architecture, that actually makes perfect sense: Instead of a single stream of narrow (CISC or RISC) instructions, every instruction word is very wide (thence VLIW), and explicitly directs the various parts of the chip on what to do.  Instead of speculative execution and parallelism by implicitly running instructions from multiple threads at once, the parallelism is made explicit in the instruction stream.  Without speculative execution, Itanium should not be vulnerable to these two problems.

So now I wonder: why is Itanium getting a microcode update?  Something doesn't quite add up here.  Perhaps what I wrote above is not 100% correct?


----------



## MarcoB (Jan 11, 2018)

There is a thread about this on Phoronix (yes, I know ), where someone stated that this microcode is only helping to mitigate the risk on Spectre. I think this could be true and that this microcode is not a patch in itself but is some kind of preparation to make the fixes of the different os's possible.


----------



## Snurg (Jan 11, 2018)

Where does this sysutils/devcpu-data stuff install to?
whereis doesn't tell anything where I can look at the files.

```
# service microcode_update onestart
Updating cpucodes...
Done.
#
```
No information in /var/log/messages either.
How do I find out whether it actually did something except of printing the message?

Regarding Itanium, the fact that it also got a patch despite being "not affected", is telltale about the trustworthiness of Intel official statements.


----------



## MarcoB (Jan 11, 2018)

Snurg said:


> Where does this sysutils/devcpu-data stuff install to?
> whereis doesn't tell anything where I can look at the files.


In /usr/local/share/cpucontrol.


> Regarding Itanium, the fact that it also got a patch despite being "not affected", is telltale about the trustworthiness of Intel official statements.


Intel is doing damagecontrol at the moment and spreading some fud. But afaik only Intel x86 is vulnerable for Meltdown, and just about all processors with branch prediction are vulnerable for Spectre.


----------



## xchris (Jan 11, 2018)

Snurg said:


> Regarding Itanium, the fact that it also got a patch despite being "not affected", is telltale about the trustworthiness of Intel official statements.



or its just routine maintenance patches


----------



## Eric A. Borisch (Jan 11, 2018)

Snurg said:


> Where does this sysutils/devcpu-data stuff install to?



`pkg list devcpu-data`


----------



## _martin (Jan 11, 2018)

ralphbsz said:


> VInstead of speculative execution and parallelism by implicitly running instructions from multiple threads at once, the parallelism is made explicit in the instruction stream.



Though execution on Itanium is explicitly parallel (hence EPIC), your statement is not true. Depending on the template used in instruction encoding you can achieve instructions to be run in parallel (doesn't mean they always are).

But Itanium does speculative loads, predicts branches, ..

All my Itanium machines I own or support are HP-UX boxes. It surprised me that Intel included those microcodes (Itanium ones) under "Linux" packages.
I'm fairly confident to say HP-UX doesn't load any microcode during boot. But this microcode in general gives me headache past few days as I came to know I know less about CPUs I thought I know.


----------



## ralphbsz (Jan 11, 2018)

Thank you for that correction.

By the way, I'm sure you know, but others may not: Itanium can also run operating systems other than HP-UX, at the minimum OpenVMS (the old Digital Equipment VAX operating system, now sold and supported by HPE) and NonStop (the old Tandem operating system, again now from HPE).  It also used to run Linux (I actually worked at HP a few cubicles away from the folks who did the first Linux port to Itanium in great secrecy), but Linux is no longer officially supported by RedHat, SUSE and the likes.


----------



## _martin (Jan 11, 2018)

ralphbsz said:


> Itanium can also run operating systems other than HP-UX,



Indeed I do ; HP (hand-to-hand with Microsoft) even made an effort to sell Superdome where you can run Windows (R) in one of the npar you would create. Some of our customers had this solution few years back.

--
I think I saw you mentioned you worked for HP in ECC thread. I still work .. well, HP->HPE->DXC, so nowadays it's more tears in the eyes than not. But it was happy days 10years ago ..


----------



## rigoletto@ (Jan 11, 2018)

For your interest, HERE.


----------



## Snurg (Jan 11, 2018)

lebarondemerde said:


> For your interest, HERE.


Either this x86info program is crap or devcpu-data fscked up the processor.
I guess the latter, because there was no notice in /var/log/messages about updating the microcode.
When run in root mode, x86info hangs. (It is the one from latest repos, installed just a few minutes ago)
When run in user mode, it says the processor is a tri-core processor with hyperthreading. It is a six-core processor with hyperthreading turned off in BIOS (to avoid thrashing).
As I have to exchange the keyboard for a cleaned one anyway, I'll reboot and check it again today or tomorrow.


----------



## rigoletto@ (Jan 12, 2018)

Snurg 

Mail the the maintainer, he is looking for feedback. Due to some Intel updates that were breaking some installations he is reworking the thing.


----------



## arnab (Jan 12, 2018)

Here is the AMD's update on the impact of Spectre & Meltdown exploits on AMD CPUs
https://www.amd.com/en/corporate/speculative-execution?sf178974629=1


----------



## Snurg (Jan 12, 2018)

I did a pkg update/upgrade to make sure system is full up-to-date, powered off, changed keyboard, and rebooted.
Now updating microcode completely fails. ("Re-evalutation of CPU flags Failed.").


----------



## _martin (Jan 12, 2018)

xchris said:


> or its just routine maintenance patches



It could be ; official stand from Intel still is - "not affected" - https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-a00039267en_us


----------



## MarcoB (Jan 12, 2018)

Snurg said:


> I did a pkg update/upgrade to make sure system is full up-to-date, powered off, changed keyboard, and rebooted.
> Now updating microcode completely fails. ("Re-evalutation of CPU flags Failed.").


Here too. I wonder if my cpu is too old?


----------



## Eric A. Borisch (Jan 12, 2018)

Snurg said:


> I did a pkg update/upgrade to make sure system is full up-to-date, powered off, changed keyboard, and rebooted.
> Now updating microcode completely fails. ("Re-evalutation of CPU flags Failed.").



That's because the port (its rc.d script, specifically) is calling cpucontrol with flags that aren't available yet in a released system.

"-e" (re-evaluate flags) added to cpucontrol in head here:
https://svnweb.freebsd.org/base/hea...ucontrol.c?r1=327597&r2=327596&pathrev=327597

And merged into stable/11 here: (About two hours ago)
https://svnweb.freebsd.org/base/sta...ucontrol.c?r1=327871&r2=327870&pathrev=327871

So. Whenever 11.2 is cut, hopefully this will be resolved. Until then, ignore it. From the initial commit, the intent (of -e) is to "[...] allow the kernel to see the changes in the CPU features after micocode update."

The port could be patched to detect if these are available yet to mute / not execute the call when it will be certain to fail. It would be nice, but I'd rather the devs work on meltdown/spectre now and clean up these bits later...


----------



## Eric A. Borisch (Jan 12, 2018)

Also of note: (as of yesterday; 1.13_2 version of devcpu-data) https://svnweb.freebsd.org/ports?view=revision&revision=458792

Revert to previous Intel microcode archive (20171117).

FreeBSD kernel changes to make use of the capabilities provided by the
new microcode update have not yet been committed. Since we do not yet
require them, allow more time for validation.​


----------



## Snurg (Jan 12, 2018)

MarcoB said:


> Here too. I wonder if my cpu is too old?


How old? Mine was released in July 2012 and is listed in Intels' list of CPUs with microcode update...



Eric A. Borisch said:


> That's because the port (its rc.d script, specifically) is calling cpucontrol with flags that aren't available yet in a released system.


I haven't yet put it into the rc.conf... just did `service microcodeblahblah onestart`...  does this also use the rc.d script?

Could it be possible to just download the microcode update from Intel and order devcpu-data to use that one?


----------



## MarcoB (Jan 12, 2018)

Snurg said:


> How old? Mine was released in July 2012 and is listed in Intels' list of CPUs with microcode update...



Mine is a dual Xeon (nocona) from 2004. It's in the list but I have my doubts about Intel releasing patches for processors of this age...


----------



## Eric A. Borisch (Jan 12, 2018)

Snurg said:


> I haven't yet put it into the rc.conf... just did `service microcodeblahblah onestart`...  does this also use the rc.d script?


Yes.


Snurg said:


> Could it be possible to just download the microcode update from Intel and order devcpu-data to use that one?


Likely, but why?


----------



## vejnovic (Jan 12, 2018)

https://svnweb.freebsd.org/base?view=revision&revision=327876


----------



## arnab (Jan 12, 2018)

Here is the Intel benchmarking results after Spectre & Meltdown patches
https://newsroom.intel.com/editoria...tial-performance-data-results-client-systems/


----------



## Snurg (Jan 12, 2018)

arnab said:


> Here is the Intel benchmarking results...


WOW! Up to 3% performance gain!
Long live Comrade Kim Jong Krzanich!


----------



## Eric A. Borisch (Jan 12, 2018)

For reference: https://wiki.freebsd.org/SpeculativeExecutionVulnerabilities


----------



## phoenix (Jan 12, 2018)

arnab said:


> Here is the Intel benchmarking results after Spectre & Meltdown patches
> https://newsroom.intel.com/editoria...tial-performance-data-results-client-systems/



Matt Dillon from DragonflyBSD would take exception to those numbers.  
http://lists.dragonflybsd.org/pipermail/users/2018-January/335643.html

There's been a few updates to Matt's numbers that show the performance penalty shrinking, but in the workloads he's tested, the performance hit is significant.

Will be interesting to see some benchmarks next month when most of the mitigations and workarounds are in place, to see how AMD compares to Intel now.


----------



## ralphbsz (Jan 13, 2018)

arnab said:


> Here is the Intel benchmarking results ...


That should be written as the Intel *on Windows* benchmarking results.

At least they have the courtesy to tell us the expected error bars: +- 3%.  So some benchmark improving by 3% is statistically perfectly expected.


----------



## Snurg (Jan 13, 2018)

Eric A. Borisch said:


> Likely, but why?


I was not sure whether cpucontrol took the right microcode file, so I thought maybe it could be worth a try to explicitly specify the file to use.

However, while looking into the thing and trying to understand, I got more confused.
As x86info hangs in root mode, and gives incorrect cpu information in user mode, I looked up the CPU info in dmesg. (Family=0x6  Model=0x2c  Stepping=2)
Now, in the Intel download for this CPU, there is a releasenote file.


> intel-ucode dirctory contains binary microcode files named in family-model-stepping pattern.


So I expected to find a file 06-2c-02 there. But there is none. The nearest models present are 2a and 2d.
In /usr/local/share/cpucontrol/ I do not see a file matching these family/model/stepping either.
So I guess that the correct file might be 06-2d-06 (concluding from the code section in this post), respective /usr/local/share/cpucontrol/m6d206d6_00000619.fw (both are identical, at least for the versions before the rollback mentioned in post #189). (It might be the 06-2a-07 file instead, didn't look into this really)
So ucode-tool apparently extracts correctly from microcode.dat file, which Intel supplied to support legacy apps, to the files in /usr/local/share/cpucontrol. A better way imho would be to directly use the binary files supplied by Intel.

Then I tried `cpucontrol -v -u /dev/cpuctlX -d /usr/local/share/cpucontrol`, as being suggested by /usr/local/etc/rc.d/microcode_update.
I felt really disappointed. No verbosity at all (no output) and nothing in the system log.

Then I tried to find out more by looking into the code. There is _no_ verbosity output code. Thus I conclude, that the verbosity flag is just a placebo setting an (unused) verbosity flag.
Edit: The verbosity output is done by WARN[X] macros but does not output. You must use -vvv to get meaningful output. Using this I found that the CPU model is being incorrectly identified - 0x0c instead of 0x2c.
Investigating this issue, I found that the method of identifying the processor model used in intel_update() is totally wrong. This sad fact is easy to find out when consulting Intel's instructions how to identify processors.​
I failed to find any code that does the transformation from cpu model/family/stepping to a particular filename.
Thus I guessed the microcode update fails because it does not get information _what_ to upload to the cpu.

Looking deeper into cpucontrol.c I got the impression that do_update() walks through _every_ file and tries passing it to intel_update() in intel.c.
In intel_update() there is a long sequence of checks, and it looks like there is something wrong in these checks, resulting in _never_ reaching the match jump label, where the actual cpu update is being done. (See also PR 192487 - cpucontrol uses unsafe procedure to detect current microcode version)

So, in my impression the whole approach is flawed. Intel provides a method to _directly_ find which microcode update file is to be applied.
Instead of just using _this_ one file, cpucontrol walks through _all_ files and fails to identify the correct one. (See also PR 219269, which requests an option for specifying a particular file directly to avoid the problems introduced by this flawed approach)

My personal guess is it's this issue why the microcode_update thing has been retracted as mentioned in post #189, until the devs decided how to fix it.


----------



## Maelstorm (Jan 13, 2018)

The AMD CPU in my machine is so old, that there will not be any microcode updates for it.  Doesn't matter since it's not an Intel CPU, I'm the only one that uses the machine, and there is no GUI (ssh access only) so there is no web browser to compromise.

With that being said, back in the early to middle 1990's while MS-DOS was still a big thing, I had to write some CPU identification code for some software that I was writing.  It's a straight forward procedure in ASM.  There are a series of steps that need to be performed.  It would detect 8086/8088, 80186/80188, 80286, 80386, 80486, and Pentium.  The procedure for everything below the Pentium would place the CPU in very specific conditions and watch the behavior.  Mainly, it would exploit known bugs in the design to check what it was.

The pivot is 286.  It would try to set a couple of bits in the flags register.  If those bit could be set, then it was at least a 286.  If not, then it was a 86/88 or an 186, 188.  To differentiate between the 86/186, it checks with the SHR instruction.  If the result was 0, then it was a 186, else it was a 188.  Then it would check for the bus width by sizing the prefetch buffer to differentiate between 88/188 or 86/186.

To detect a 386 or higher, it would check to see if bit 14 of flags could be set.  If not, then it really was a 286, else we test bit 23 of flags to see if it could be set.  If so, then it's at least a 486.  Then it would test bit 22 in flags and toggle.  If the result was 0, then it really was a 486.  But it if wasn't, that meant that it was a Pentium or higher and would return 586.  That's as high as it would go.

Here's the code for that function written in Turbo Assembler:


```
; *** Detect Main Processor Type

PROC DETECTCPU                 ; Called as function
  LOCAL CPUTYPE:WORD
  LOCALS @@
  PUSHF                        ; Save machine status word onto stack
  POP AX                       ; Load last push into AX register from stack
  AND AX, 03FFFH               ; Clear the 2 msbs
  PUSH AX                      ; Save AX register onto stack
  POPF                         ; Restore machine status word
  PUSHF                        ; Save machine status word onto stack
  POP AX                       ; Load last push into AX register from stack
  AND AX, 0C000H               ; Mask all off but the 2 msbs
  JE @@CPU80286                ; If not set then we have a 286 or higher
  MOV CL, 021H                 ; Load CL register with shift value
  MOV AL, 0FFH                 ; Load AL with all ones
  SHR AL, CL                   ; Shift AL to the left
  CMP AL, 0                    ; Does AL = 0?
  MOV AX, 188                  ; Load AX register with 80188 cpu code
  JNE @@DOBUS                  ; If AL = 0 then jump
  MOV AX, 88                   ; Else load AX register with 8088 cpu code
 @@DOBUS:                      ; Routine to test width of data bus
  MOV BX, 1                    ; Put 1 into BX register
  MOV AL, [CS:TESTINST]        ; Get test instruction
  XOR AL, 8                    ; Change it
  MOV [CS:TESTINST], AL        ; Write it back to the code segment
  NOP                          ; These are to fill the processor queue
  NOP                          ; Processor no operation instruction
  NOP                          ; Processor no operation instruction
  NOP                          ; Processor no operation instruction
 TESTINST DB 043H              ; The test instruction
  SUB AX, BX                   ; Subtract result from cpu code for proper id
  MOV [CPUTYPE], AX            ; Put AX into CPU result variable
  JMP @@EXIT                   ; Jump to exit routine
 @@CPU80286:                   ; 80286 test begins here
P286                           ; Enable 286 instructions
  PUSHF                        ; Push flags onto stack
  POP AX                       ; Pop flags into AX register
  OR AX, 04000H                ; Set bit 14
  PUSH AX                      ; Push AX register onto stack
  POPF                         ; Pop AX register into flags
  PUSHF                        ; Save flags once again
  POP AX                       ; And put it back into AX register
  AND AH, 040H                 ; Mask all but bit 14
  CMP AH, 040H                 ; Does bit 14 = 1?
  JE @@CPU80386                ; If so then we have at least a 386
  MOV [CPUTYPE], 286           ; Load 80286 cpu code into result variable
  JMP @@EXIT                   ; Jump to exit routine
 @@CPU80386:                   ; 80386 test begins here
P386                           ; Enable 386 instructions
  PUSHFD                       ; Push extended flags onto stack
  POP EAX                      ; Load EAX register with Eflags
  MOV EBX, EAX                 ; Save to EBX register
  AND EBX, 040000H             ; Mask off all but bit 23
  XOR EAX, 040000H             ; Toggle bit 23
  PUSH EAX                     ; Save EAX to stack
  POPFD                        ; Restore flags
  PUSHFD                       ; Save flags
  POP EAX                      ; Load EAX register with Eflags from stack
  AND EAX,040000H              ; Mask off all but bit 23
  MOV [CPUTYPE], 386           ; Load 80386 cpu code into result variable
  CMP EAX, EBX                 ; Did the toggle hold?
  JE @@EXIT                    ; If not then jump to exit routine
P486                           ; Enable 486 instructions
  PUSHFD                       ; Save flags onto stack
  POP EAX                      ; And load into EAX register
  XOR EAX, 040000H             ; Toggle bit 23 of flags
  PUSH EAX                     ; Push EAX register onto stack
  POPFD                        ; And restore into Eflags register
  MOV [CPUTYPE], 486           ; Load 80486 cpu code into result variable
  PUSHFD                       ; Push extended flags onto stack
  PUSHFD                       ; Again
  POP ECX                      ; Load into ECX register
  POP EAX                      ; Load into EAX register
  XOR EAX, 020000H             ; Toggle bit 22 in EAX register
  PUSH EAX                     ; Save EAX onto stack
  POPFD                        ; Restore Eflags
  PUSHFD                       ; Save Eflags once again
  POP EAX                      ; Load back into Eflags
  XOR EAX, ECX                 ; Toggle all bits
  JZ @@EXIT                    ; Cpu really is a 486 so jump to exit routine
 @@CPU80586:                   ; Cpu is a 586 or higher
  MOV [CPUTYPE], 586           ; Put 586 into return variable
 @@EXIT:                       ; Exit routine begins here
P8086                          ; Enable 8086/8088 instructions
  MOV AX, [CPUTYPE]            ; Put result variable into AX register
  RET                          ; Return to caller
ENDP
```



Snurg said:


> I was not sure whether cpucontrol took the right microcode file, so I thought maybe it could be worth a try to explicitly specify the file to use.



As a student of computer science myself, what I do not understand is why use the shotgun approach rather than use Intel's procedure to determine which file to load?  I mean, the procedure is published by the CPU vendor so why not use it?  It would cause a lot less headaches if people coded to spec as documented instead of trying to do something quick and dirty, which might bite you in the long run.

But that's me.


----------



## Snurg (Jan 13, 2018)

Maelstorm said:


> As a student of computer science myself, what I do not understand is why use the shotgun approach rather than use Intel's procedure to determine which file to load?  I mean, the procedure is published by the CPU vendor so why not use it?  It would cause a lot less headaches if people coded to spec as documented instead of trying to do something quick and dirty, which might bite you in the long run.


Basically the procedure is simple. Take the the cpu family, model, stepping and microcode version. Then look what of those files is the next successor (same family/model, higher microcode version).
With the information Intel provided and the easy-to-understand file naming convention, one can even manually easily identify which file is the correct one.
The approach used by the cpucontrol program is completely different than this.

I am playing around with cpucontrol.c and intel.c atm, implementing an option -f to manually specify the microcode file to load, and correcting the code in intel.c regarding processor and microcode identification so it can correctly determine whether the file given as parameter actually is a compatible one.
When the results seem OK, I'll uncomment the actual uploading code and see what happens.

I don't think that an option to specify a microcode file manually is a shotgun approach, because there are (albeit rare) use cases even when the algorithm to determine the correct file has been implemented. (think of microcode testing, etc).

When this works, the next step would be to correct the code in cpucontrol.c to find just that file and feed it to intel_update().
When this is done, I'll submit that in a PR as suggestion to the devs. The reason is that I feel annoyed by the fact that there is still no information when we FreeBSD guys will get our microcode update, even 10 days after the embargo end. I want this to happen (at least for me) before the first meltdown malwares start circulating. I don't want to be hacked just by some malicious javascripts I drive by (Microsoft Security has reportedly already made working proof-of-concept exploit scripts for this)

Your CPU detecting code is a really sweet hack  Today this is much easier... The basic information about cpuid regarding this is very well explained in figure 3-6 on page 3-204 in Intels instruction reference.


----------



## Maelstorm (Jan 14, 2018)

Snurg said:


> I don't think that an option to specify a microcode file manually is a shotgun approach, because there are (albeit rare) use cases even when the algorithm to determine the correct file has been implemented. (think of microcode testing, etc).



I didn't say that specifying a microcode file manually was the shotgun approach.  What I was referring to was the implementation of cpucontrol.c and intel.c that you described which goes through and tries each file until something loads.



Snurg said:


> The reason is that I feel annoyed by the fact that there is still no information when we FreeBSD guys will get our microcode update, even 10 days after the embargo end. I want this to happen (at least for me) before the first meltdown malwares start circulating.



I believe that Intel has already released the microcode.  Microcode is not OS or BIOS specific.  It is CPU specific.  OS doesn't matter as long as you have a tool to load the file into CPU.



Snurg said:


> Your CPU detecting code is a really sweet hack  Today this is much easier... The basic information about cpuid regarding this is very well explained in figure 3-6 on page 3-204 in Intels instruction reference.



I originally wrote that code while I was still in high school in the late 1980's to early 1990's when there was several different types of x86 CPUs out there with way different specs.  I posted it to a BBS and it spread from there.  The code was originally designed to work with Borland's Turbo Pascal.  But it can be used with any language.  It was part of a game engine that I was writing.  I was going to sell it, but then Windows 95 came on to the scene and it was rendered obsolete.

Believe it or not, there are still some 80486's out there still working.  Solid equipment if a bit dated.


----------



## fernandel (Jan 14, 2018)

Maelstorm said:


> I
> 
> 
> Believe it or not, there are still some 80486's out there still working.  Solid equipment if a bit dated.



My friend has still working 286 with DOS, 50 MB Quantum HD and 1 MB of RAM and program which I made with Clipper for his winery is working still. The 15'' VGA Philips monitor works too .


----------



## Eric A. Borisch (Jan 15, 2018)

An interesting read on the coordinated disclosure: https://www.theverge.com/2018/1/11/...tre-disclosure-embargo-google-microsoft-linux


----------



## Deleted member 30996 (Jan 15, 2018)

I updated sysutils/devcpu-data today and ran it again on the same machine with different results:


```
root@relentless:/ # service microcode_update start
Updating CPU Microcode...
Please update your system in order to update CPU microcode.
Done.
root@relentless:/ # grep micro /var/log/messages
root@relentless:/ #
```
Now what? It is up to date.


```
root@relentless:/ # freebsd-version -k
11.1-RELEASE-p4
root@relentless:/ # freebsd-version -u
11.1-RELEASE-p6
```


----------



## MarcoB (Jan 15, 2018)

Yeah here too, but my system is 11.1-STABLE from august 2017 so that's possible. /usr/sbin/cpucontrol is a base program.


----------



## Eric A. Borisch (Jan 15, 2018)

Trihexagonal said:


> I updated sysutils/devcpu-data today and ran it again on the same machine with different results:
> 
> 
> ```
> ...



It’s being prepared for whenever the new release (which supports -e) is cut.

https://svnweb.freebsd.org/ports/he..._update.in?r1=459084&r2=459083&pathrev=459084


----------



## PacketMan (Jan 16, 2018)

So, since I am about to buy a new system, AMD based, if I wait long enough, say April 2018, would the (1st generation) Ryzen CPU, and motherboard, I buy already have these microcode updates done?  I say 1st generation Ryzen, because I understand 2nd generation will be released in April, which I don't think I am buying.


----------



## shepper (Jan 16, 2018)

PacketMan said:


> ...would the (1st generation) Ryzen CPU, and motherboard, I buy already have these microcode updates done?



CPU microcode is loaded during boot from storage media (hard drive, ssd, etc) and goes away when the system is powered off.


----------



## Phishfry (Jan 17, 2018)

Here is a good writeup on how FreeBSD got shortchanged on the embargo.
http://www.daemonology.net/blog/2018-01-17-some-thoughts-on-spectre-and-meltdown.html


----------



## _martin (Jan 17, 2018)

So, sparcs are affected too: https://www.theregister.co.uk/2018/01/16/oracle_quarterly_patches_jan_2018/


----------



## Eric A. Borisch (Jan 17, 2018)

In CURRENT: https://svnweb.freebsd.org/base?view=revision&revision=328083 -- MFC in 2 weeks.


----------



## PacketMan (Jan 17, 2018)

shepper said:


> CPU microcode is loaded during boot from storage media (hard drive, ssd, etc) and goes away when the system is powered off.



OKay, but my question still remains: Will new releases of the current generation of CPU and motherboards have the fix built into them, or will this piece of microcode go on for the foreseeable future? In other words will newly made batched of CPUs and motherboards incorporate the permanent fix, or will it have to be new generations of CPU (think Ryzen 2nd or 3rd gen, or Intel Core i5-9xxx for example). After all this was reported as a CPU hardware problem, that itself can't be fixed, so the work around was kernel and/or micocode updates. So all I am asking is can we expect future versions of these CPU to have the necessary hardware changes baked inside, or will we still need this work around?


----------



## ronaldlees (Jan 17, 2018)

Phishfry said:


> Here is a good writeup on how FreeBSD got shortchanged on the embargo.
> http://www.daemonology.net/blog/2018-01-17-some-thoughts-on-spectre-and-meltdown.html



I had forgotten about that site.  Thanks for the memory recharge.


----------



## azathoth (Jan 17, 2018)

Trihexagonal said:


> I updated sysutils/devcpu-data today and ran it again on the same machine with different results:
> 
> 
> ```
> ...






```
root@realfascism:~ # freebsd-version -k
11.1-RELEASE-p4
root@realfascism:~ # freebsd-version -u
11.1-RELEASE-p6
```

same here! why am I not on 6? is 6 stuff for non amd64?


----------



## Eric A. Borisch (Jan 17, 2018)

azathoth said:


> same here! why am I not on 6? is 6 stuff for non amd64?



No kernel changes from -p4 to p6:
`# svn diff --summarize -r r325875:HEAD
M       UPDATING
M       crypto/openssl/crypto/bn/asm/rsaz-avx2.pl
M       crypto/openssl/crypto/bn/asm/x86_64-mont5.pl
M       crypto/openssl/crypto/x509v3/v3_addr.c
M       crypto/openssl/ssl/ssl.h
M       secure/lib/libcrypto/amd64/rsaz-avx2.S
M       secure/lib/libcrypto/amd64/x86_64-mont5.S
M       sys/conf/newvers.sh`


----------



## Minbari (Jan 17, 2018)

azathoth said:


> ```
> root@realfascism:~ # freebsd-version -k
> 11.1-RELEASE-p4
> root@realfascism:~ # freebsd-version -u
> ...



To have same version you can build the kernel from sources.

ex.

```
freebsd-version -ku                                                                                                                    
11.1-RELEASE-p6
11.1-RELEASE-p6
```


----------



## shepper (Jan 17, 2018)

PacketMan said:


> OKay, but my question still remains: Will new releases of the current generation of CPU and motherboards have the fix built into them, or will this piece of microcode go on for the foreseeable future?



The fix will not be built into the motherboard.  It is more like a firmware update and in this instance, Intel/AMD have existing cpu microcode which is in the process of being updated to address the security issue.  The advantage of microcode/firmware, is that the issue can be dealt with by a download rather than buying new hardware.

Firmware/microcode is usually propriatory/closed source.  The FreeBSD developers have written a utility to load the microcode and have to hope that Intel/AMD provide secure, compatible code. The FreeBSD developers may not be able to audit the code without a Non-Disclosure-Agreement.


----------



## PacketMan (Jan 17, 2018)

shepper said:


> The fix will not be built into the motherboard.



Okay thanks. However I am not asking really about the motherboard.  All I am trying to determine is if/when future releases of CPUs from Intel and AMD (AMD really for me), will not have this hardware issue inside the CPU. When will the issue be fixed inside the CPU, and thus a workaround outside the CPU is not required.


----------



## Beeblebrox (Jan 18, 2018)

....Aaand a new *embargoed* vulnerability:
https://skyfallattack.com/
Not much info there, just a clue


> Skyfall and Solace are two speculative attacks based on the work highlighted by Meltdown and Spectre.



The *BDS's will probably be kept in the dark, again!


----------



## Eric A. Borisch (Jan 18, 2018)

Beeblebrox said:


> ....Aaand a new *embargoed* vulnerability:
> https://skyfallattack.com/
> Not much info there, just a clue
> 
> ...



Where did this surface?


----------



## Phishfry (Jan 18, 2018)

Colins blog mentioned they did not get notice until the day before Christmas. Intel was working with Linux people since July on the issue.


----------



## ralphbsz (Jan 18, 2018)

And with Microsoft.  I presume Apple was informed too.  Welcome to the reality of market share.


----------



## PacketMan (Jan 18, 2018)

I don't think this has been posted yet.
https://www.theregister.co.uk/2018/01/18/red_hat_spectre_firmware_update_woes/


----------



## SirDice (Jan 18, 2018)

azathoth said:


> same here! why am I not on 6? is 6 stuff for non amd64?


P5 and P6 were patches for OpenSSL and did not affect the kernel. Hence the kernel wasn't updated.
https://www.freebsd.org/security/advisories.html


----------



## masterofnull (Jan 18, 2018)

Beeblebrox said:


> ....Aaand a new *embargoed* vulnerability:
> https://skyfallattack.com/
> Not much info there, just a clue
> 
> ...


Why would they release just the page for the vulnerability and not the actual information?

This seems more like PR guys just trying to take advantage of the Spectre and Meltdown hype...


----------



## Snurg (Jan 19, 2018)

WTF?  Can this be true??

The microcode updater program I am working on shows this with the -i(dentify) option:

```
# cpupdate -i                                      
Found CPU(s) from Intel                                                        
/dev/cpuctl0 identification successful!                                        
Processor Core: 0                                                              
ProcessorType:  00
ExtFamily: 00  ExtModel: 01                                                    
IntFamily: 06  IntModel: 0A  Stepping: 05                                      
-> Family: 06  Model:    1A                                                    
Flags: 2                                                                      
-> Family: 06  Model:    1A  uCodeRev: 001B                                    
/dev/cpuctl1 identification successful!                                        
<snipped identical output for the other cores>
#
```

This is confirmed by dmesg:

```
CPU: Intel(R) Xeon(R) CPU           W3520  @ 2.67GHz (2666.72-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x106a5  Family=0x6  Model=0x1a  Stepping=5
```

And now, I look at the microcode update file supplied by Intel in the Jan 8 update release:

```
# cpupdate -f /etc/microcode-20180108/intel-ucode/06-1a-05
Update file properties:
Header version 1 (0x1)
Revision 25 (0x19)
Date 06212013
File is to be used for processors with these stats:
ProcessorType:  00
ExtFamily: 00  ExtModel: 01
IntFamily: 06  IntModel: 0A  Stepping: 05
-> Family: 06  Model:    1A
Loader revision required to upload this microcode: 1 (0x1)
Processor Flags 3 (0x00000003)
Data size 10192 (0x27d0)
Has no extended header.
#
```

Can this be real?
Look at the date - Jun 21, 2013.
Look at the microcode revision: 0x19.
It is _lower_ than the built-in version of the processor...
Am I hallucinating?

The microcode update file format is described in detail in section 9.11.1 (pages 9-28 to 9-31) of the
Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3A.
I believe I programmed strictly after the Intel instructions.

Further examinations of other microcode files from that release seem no less irritating:

```
# cpupdate -f /etc/microcode-20180108/intel-ucode/06-17-06
Update file properties:
Header version 1 (0x1)
Revision 1551 (0x60f)
Date 09292010
File is to be used for processors with these stats:
ProcessorType:  00
ExtFamily: 00  ExtModel: 01
IntFamily: 06  IntModel: 07  Stepping: 06
-> Family: 06  Model:    17
Loader revision required to upload this microcode: 1 (0x1)
Processor Flags 1 (0x00000001)
Data size 4048 (0xfd0)
Has no extended header.
#
```

This release seems even older. Sep 29, 2010.
Examining more of the files gives me the impression most of them seem to be quite old microcode releases, some around 10 yrs old or more...

I wonder what is going on... so let's examine the biggest files, assuming these are for the most modern, most complex processors of which still some are in production use.

```
# cpupdate -f /etc/microcode-20180108/intel-ucode/06-4e-03
Update file properties:
Header version 1 (0x1)
Revision 194 (0xc2)
Date 11162017
File is to be used for processors with these stats:
ProcessorType:  00
ExtFamily: 00  ExtModel: 04
IntFamily: 06  IntModel: 0E  Stepping: 03
-> Family: 06  Model:    4E
Loader revision required to upload this microcode: 1 (0x1)
Processor Flags 192 (0x000000c0)
Data size 99280 (0x183d0)
Has no extended header.
#
```
The biggest file is from Nov 17, 2017. Quite recent, but still from last year.

After examining a few of the biggest files which all were from Nov 2017, I finally managed to find a file updated this year, which is more recent than Intels' last microcode release. Which was on Nov 17, 2017:

```
# cpupdate -f /etc/microcode-20180108/intel-ucode/06-9e-0b
Update file properties:
Header version 1 (0x1)
Revision 128 (0x80)
Date 01042018
File is to be used for processors with these stats:
ProcessorType:  00
ExtFamily: 00  ExtModel: 09
IntFamily: 06  IntModel: 0E  Stepping: 0B
-> Family: 06  Model:    9E
Loader revision required to upload this microcode: 1 (0x1)
Processor Flags 2 (0x00000002)
Data size 98256 (0x17fd0)
Has no extended header.
#
```
Yeah... Jan 4, 2018. At least one file.

I have to admit, I did _not at all _expect to find out such when attempting to test the microcode uploader.

```
# cpupdate
Usage: cpupdate [-i] | [-h] | -f <microcodefile> | -u <datadir> [-q]
  -i  show processor information
  -f  show version information of microcode file
  -u  update microcode using microcode files in <datadir>
  -q  quiet mode
  -h  show this help
#
```

I can still not believe what I see.
I will add another function to give a neat output of all microcode file stats, each a line.
So one can see at a glimpse what internal date and revision every microcode file has.

After that I will put the program onto Github. This will be today afternoon/evening (German time), as it is now 5 a.m. here and I am tired as hell.

So everybody can check out whether I made some mistake, or something other is foul.
*
Did Intel actually release updated microcodes?
Or did they only pretend to do so, hoping that nobody actually will take a deep look into the microcode files and notice the con art?

If it's true what I suspect, I guess Intel will have to explain some more things.*


----------



## Maelstorm (Jan 19, 2018)

Well now, that's very interesting.  If they are trying to con people, it may be so that they can avoid a recall.  Lull people into a false sense of security.  Either that, or it's a test microcode that they had laying around and they rushed it out the door hoping it will fix the problem.  Or it could be just a typo.  The issues with Intel CPUs may not be able to be fixed with microcode, which means that there will be a recall.  Imagine having a recall on every CPU that you sold over the past 3 years.  It will be in the billions, if not tens of billions.

I am actually surprised that AMD hasn't really capitalized on the Intel bug.  All is fair in love and war, and business is a war between companies.  Perhaps AMD's strategy is to just sit back, watch what happens, and let the chips fall where they may (pun intended).


----------



## PacketMan (Jan 19, 2018)

Is it possible that these microcode updates were written as early as Jun 21, 2013 because they knew about the problem as early as Jun 21, 2013?


----------



## gofer_touch (Jan 19, 2018)

If that is true then it might signify that certain customers might have been provided with the fix...government agencies and so on, while everyone else was left in the cold.


----------



## hotaronohanako (Jan 19, 2018)

gofer_touch said:


> If that is true then it might signify that certain customers might have been provided with the fix...government agencies and so on, while everyone else was left in the cold.


if thats the case maybe is some kind of technologic  *Apartheid *


----------



## Deleted member 45312 (Jan 19, 2018)

I did some test with Spectre POC from https://spectreattack.com/spectre.pdf.

Firstly with my Intel Pentium G2010 CPU original microcode: POC succeeded.
Tried with updated microcode from ports: POC succedeed.

As Intel screwed me over, I decided to buy an AMD CPU based motherboard: Asus M5A78L-M LX3 with AMD FX 6300 CPU.
With original microcode 0x600081c: POC succeeded.
With new microcode 0x600084f from ports: POC failed.

Interesting because the microcode 0x600084f from ports was made available by AMD on 2016-03-17.


----------



## Deleted member 30996 (Jan 19, 2018)

I'm considering shelving my Netgear router and either re-purposing one of my laptops or dragging out my old pfSense tower router/firewall and take my chances with that.


----------



## shepper (Jan 19, 2018)

Trihexagonal said:


> I'm considering shelving my Netgear router



Many routers utilize a linux OS and per the GPL2 license, they were required to publish their source.  Some projects have taken that source and updated kernels and userland.  My Trendnet router initially utilized linux kernel 2.6 but is now running 4.4 lts.  See LEDE/OpenWRT.  Note the web site is slow right now -  perhaps due to LEDE and Openwrt merging?

Edit:  FreeBSD also has a router project although it does not support as many devices.


----------



## Crivens (Jan 19, 2018)

I would like to add some points to this thead.

Is it only me or is meltdown a wee bit bigger than most think it is?
To explain this, meltdown lets you read memory even if you do not have access to
it, right? But, even when that hole is plugged, you still need to do something
more. For those who practice the dark arts of verilog or other means to tell
electrons which way to go, there is the term "strobe register". This is a
register in a hardware interface that acts as a trigger for some action. For
some chip, you would set up the registers for some operation and then pull the
trigger for that operation by accessing that strobe register. Now imagine a
speculative memory load instruction behind a conditional branch which simply
goes bart simpson on some DMA controller in some part of the machine. Maybe this
can even be used in a more surgical way, if possible, but I am sure there were No Serious
Attempts thinking in that direction, right?

Also, on the 34C3, there was a talk about x86 micocode and what you never wanted
to ask about it. I had to leave that one after about 10 minutes because junior
was getting bored. However, they demonstrated that on at least some CPUs they
were reverse engineering micocode the hard way, by flipping bits in the stream
and looking with a debugger what happens to register contents. Maybe there are
systems where there is no, or inadequate, protection against messing with
microcode. Maybe I can watch the recording tonight and see what they did. In the
worst case, you can change the microcode with some javascript or maybe by
triggering certain rules in the JIT enabled firewall?


----------



## ralphbsz (Jan 19, 2018)

If people (outside Intel) can take an Intel microcode file and modify it, and then download that modified file to the CPU and get it to execute with that modified microcode, then there is no reason to trust the CPU chip.  I had never bothered to think through how Intel (and AMD and Sun and IBM and ...) secure the microcode; some cryptographic signature that's verified by the hardware would have seemed plausible.  But if the CPU does not authenticate the microcode before accepting it, then the bottom falls out.

And those of you who have ever worked on secure computing devices (TCB, self-encrypting disks, key distribution and the like) should give up all hope at this thought.

In the end, as I keep pointing out, this is all solving the wrong problem.  All these bugs allow a bad guy to do things they shouldn't do, once they are running code on your computer.  The better solution is to prevent them from getting on your computer in the first place.  And as discussed over and over, that simply means not running web browsers with javascript (and the like) on machines that also have information that needs to be kept secure.  The real problem is that our computer culture has embraced bells and whistles in web pages which need general-purpose programming languages, and forgotten in the process that these things need to be sandboxed.  Early in the development of Java (not javascript), there was serious consideration about sandboxing and running applets with reduced privileges; all that seems to have been forgotten again, just so we can serve picture galleries and auto-playing videos every time we need some simple technical information.  Really, yesterday I had too look up what model stand is required for Pearl Philharmonic tom drums, and it took 5 minutes, because the web site of Pearl Percussion insists on spamming me with all forms of advertising before the javascript mouse-over menus allow me to click on "specifications".  We think of the web as a machine to deliver the eyeballs of the users to advertiser.

Quote from Douglas Adams: "First we thought the PC was a calculator. Then we found out how to turn numbers into letters with ASCII — and we thought it was a typewriter. Then we discovered graphics, and we thought it was a television. With the World Wide Web, we've realized it's a brochure."


----------



## JAW (Jan 19, 2018)

Snurg said:


> WTF?  Can this be true??
> 
> So everybody can check out whether I made some mistake, or something other is foul.
> *
> ...



It's not that microcode updates are applied incrementally? So the package intel releases contains all micrcode updates going back?


----------



## Snurg (Jan 19, 2018)

I thought about it and decided it would be the best to make a small Perl script that just puts out a sorted list of the internally stored release dates of Intel's microcode files.

This enables everybody to check out the thing easily. As I currently do not have a microcode file that is more recent than what is hard-coded (respective uploaded by the BIOS) in the processors I own, I have no way of actually testing my microcode updater anyway without hacking the files. Thus I am in no hurry to release the program asap, will do that later today or tomorrow.

So here is the list of microcode files supplied by Intel with their Jan 8, 2018 update, sorted by their internal release date:
(YYYY/MM/DD:  Family-Model-Stepping)

```
1998/06/10:  06-03-02
1998/08/11:  06-07-01
1999/03/12:  06-06-0d
1999/05/05:  06-06-00
1999/05/05:  06-06-05
1999/05/05:  06-06-0a
1999/05/12:  06-05-02
1999/05/25:  06-05-00
1999/05/25:  06-05-01
1999/06/28:  06-05-03
1999/09/10:  06-07-03
1999/09/21:  06-08-01
1999/09/22:  06-07-02
1999/10/15:  06-08-03
2000/01/10:  06-0a-00
2000/03/06:  06-0a-01
2000/05/05:  06-08-06
2000/11/02:  06-08-0a
2001/02/15:  06-0b-01
2002/01/10:  06-0b-04
2002/07/16:  0f-00-07
2002/07/16:  0f-00-0a
2003/05/02:  0f-01-02
2003/06/04:  0f-02-07
2003/06/05:  0f-02-04
2004/05/11:  0f-03-02
2004/08/05:  0f-02-06
2004/08/11:  0f-02-05
2004/08/11:  0f-02-09
2004/10/17:  06-0d-06
2004/11/09:  06-09-05
2005/04/21:  0f-03-03
2005/04/21:  0f-03-04
2005/04/21:  0f-04-01
2005/04/21:  0f-04-03
2005/04/21:  0f-04-04
2005/04/21:  0f-04-07
2005/04/21:  0f-04-09
2005/11/15:  06-0e-08
2005/12/14:  0f-04-0a
2005/12/15:  0f-06-02
2005/12/15:  0f-06-04
2006/04/26:  0f-06-05
2006/05/01:  06-0e-0c
2006/05/08:  0f-04-08
2006/07/14:  0f-06-08
2009/04/10:  06-1c-02
2009/08/25:  06-1c-0a
2009/10/23:  06-26-01
2010/09/28:  06-17-0a
2010/09/29:  06-17-06
2010/09/29:  06-17-07
2010/09/30:  06-0f-06
2010/09/30:  06-1d-01
2010/10/02:  06-0f-02
2010/10/02:  06-0f-07
2010/10/02:  06-0f-0a
2010/10/02:  06-0f-0d
2010/10/03:  06-0f-0b
2010/10/04:  06-16-01
2012/05/22:  06-2d-06
2013/06/12:  06-2a-07
2013/06/17:  06-2d-07
2013/06/18:  06-2f-02
2013/06/19:  06-3e-06
2013/06/21:  06-1a-04
2013/06/21:  06-1a-05
2013/06/26:  06-25-02
2013/06/28:  06-25-05
2013/08/20:  06-1e-05
2014/05/29:  06-3e-07
2015/02/26:  06-3a-09
2016/06/02:  06-56-04
2017/03/01:  06-4f-01
2017/03/25:  06-5c-09
2017/11/16:  06-4e-03
2017/11/16:  06-5e-03
2017/11/17:  06-3d-04
2017/11/17:  06-3f-02
2017/11/17:  06-3f-04
2017/11/17:  06-47-01
2017/11/20:  06-3c-03
2017/11/20:  06-45-01
2017/11/20:  06-46-01
2017/12/01:  06-3e-04
2017/12/08:  06-55-04
2017/12/16:  06-56-02
2017/12/16:  06-56-03
2017/12/26:  06-7a-01
2018/01/04:  06-8e-09
2018/01/04:  06-8e-0a
2018/01/04:  06-9e-09
2018/01/04:  06-9e-0a
2018/01/04:  06-9e-0b
```

The oldest files are almost 20 years old!
Only a few files have been updated after the Meltdown thing became known to Intel.

So I am having a hard time to believe that Intel's statement is correct, that they provided updates for about 90% of the processors and will provide updates for the remaining ones until end of January.

What do you think?

Anyway, here is the Perl script with which I produced the list above:

```
#!/usr/bin/env perl
use strict;
use warnings;

my $dir = '/home/myname/Downloads/microcode-20180108/intel-ucode';
my @updatefiles = ();
opendir( DIR, $dir) or die "Cannot open directory\n";
my @files = readdir( DIR);
closedir( DIR);
foreach my $file (@files) {
  next if (-d $file);
  my $fpath = "$dir/$file";
  open FILE, $fpath or die $!;
  my $header;
  my $count = read( FILE, $header, 64);
  close FILE;
  my ( $header_version, $update_revision, $date) = unpack( 'N' x 3, $header );
  my ( $month, $day, $decade, $year) = unpack( 'c' x 4, pack ('I', $date));
  $year &= 0xff;
  push @updatefiles, sprintf "%02X%02X/%02X/%02X:  %s\n", $decade,  $year, $month, $day, $file;
}
foreach (sort @updatefiles) { print $_; }
```
Just copy+paste the script, change the directory path in the "my $dir = ..." line to where you unpacked the archive downloaded by Intel, and see yourself.

I guess it will be interesting how Intel will explain this.

Edit:


JAW said:


> It's not that microcode updates are applied incrementally? So the package intel releases contains all micrcode updates going back?


No. There is only one file to be applied, this is not incremental. The file name format is FF-MM-SS, two hex nibbles each for family, model, stepping respective, so you can easily find which file is to be applied to your processor.


----------



## Crivens (Jan 19, 2018)

In the end, it is the complexity that gets you.


----------



## Snurg (Jan 19, 2018)

ralphbsz said:


> ... secure the microcode; some cryptographic signature that's verified by the hardware would have seemed plausible.  But if the CPU does not authenticate the microcode before accepting it, then the bottom falls out.


 Well, according to section 9 (microcode updating) of the Intel programmers handbook, there is some encryption and "security checking" for processors P6 and later. These should return the error code "SECURITY_FAILURE" in case the cryptographic checksum is invalid. With older processors, they thus admit that every program can freely put into the microcode what (s)he wants. But I have little trust in Intel anymore, so I will believe the "security" thing only if it has been independently verified.


----------



## w0w (Jan 19, 2018)

Just download older archives and compare checksums of  MCU in different releases, not dates, also read release notes. https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File
The last archive contains ALL MCU over decade or even more, but this does not mean every MCU is updated every time, when INTEL releases new archive. I walked right into it also, and lost 2 hours installing old MCU onto my old x3350 and yes it was same old as 2010.  I don think any cpu older then 5 years will get MCU ever.


----------



## shepper (Jan 19, 2018)

On the OpenBSD side of the aisle
UnDeadly - CPU microcode update


----------



## Phishfry (Jan 19, 2018)

w0w said:


> I don think any cpu older then 5 years will get MCU ever.


I wonder how far back they do update the microcode. Maybe one Generation?
5 years sound generous looking at those MCU dates.


----------



## Snurg (Jan 19, 2018)

w0w shepper
The strange thing still is that the microcodes Intel released with their Jan 8 "update", as well as their older releases, like that from Nov 17, 2017, and the earlier ones are _not_ the most recent.
For example, they seem *not* to contain the memory sinkhole bug updates for the processors I have.

The list I posted above in post #238 suggests that Intel _never released updated microcodes against that nasty sinkhole bug to the public._
But, the fact that manufacturers like HP released BIOS updates that upload updated microcodes to the affected CPUs proves that there exist updates.

Thus the _only_ way to protect against memory sinkhole bug for computers that were not BIOS-updated by their manufacturers seems to extract the microcodes from HP (or other manufacturers') BIOS upgrades, like described in the last post of this Gentoo forums' thread.

*This puts up the question why Intel does not give these crucial safety fixes to the public.*

To me, it looks like that hotaronohanako could be correct.
Maybe only governments and manufacturers with sufficient pressure power, like HP, actually get microcode updates, leaving all others vulnerable on purpose.

For example, Trihexagonal pointed to an interesting article in this thread that Intel was willing to provide a way to disable the IME backdoor only after pressure from the NSA.
This leaves me with the feeling that Maelstorm might be correct, that the whole "update" thing has *only the purpose to lull people into a false sense of security...*



Phishfry said:


> I wonder how far back they do update the microcode. Maybe one Generation?
> 5 years sound generous looking at those MCU dates.


I understood the wording of Intel that way, that they promised to deliver updates for all those processors listed on their update page. Apparently they only pretend to do so, calculating that nobody, or only a few people will notice, and that the broad public won't take notice.
I got the impression, and from the posts on various forums, I know that many others also interpreted the wording "_This download is valid for the product(s) listed below_" that way, that there would be patches included for the processors displayed in the list on the microcode download page.

Edit:


w0w said:


> The last archive contains ALL MCU over decade or even more


Sadly this is incorrect.
The archive (and all the older ones that I examined) do not contain all updates. Intel itself admitted that there are microcode updates only for about 90% (i.e. about 9 models) of their most recent cpus. For example, I was unable to find updates for the 36xx/56xx series. And these are one of these affected by the memory sinkhole thing. However, there exist updated microcodes against that bug, issued more than a year ago. The only way to obtain them I know of is to extract them from HP BIOS update blobs, like described in the Gentoo forum link above.


----------



## Snurg (Jan 20, 2018)

I just got an email from a guy who was in contact with Intels' support staff, that Intel told him per email that *Intel will never release a microcode update for the Xeon E/X36xx and E/X56xx processors*.
So it seems confirmed that Intel did not tell the truth to the public when they made people believe they'd get microcode updates.
This really sucks, as my main computers use these processors.

I guess I will _*never ever again buy a computer with Intel processor*_.


----------



## Chris_H (Jan 20, 2018)

Heh, well, unless it's pre 2012. Or so it seems. I'm guessing the prices on Intel CPU's should be dropping significantly.
Not that I really care. There's just too many other options, and those _other_ options are looking a _whole_ lot better. 

--Chris


----------



## w0w (Jan 20, 2018)

Snurg said:


> Sadly this is incorrect.


Yes you are right. I just mean it contains MCU for a lot of CPU but not updated recently.
If we compare 20180108 and 20171117, we find only those MCU files changed, that are listed in the release note.  I don't know who is the first stated that Intel would release MCU for all CPUs affected, but it was not true.

EDIT:

It's possible that UBU contains more recent versions of microcode than Intel provides for public.
EDIT2:

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr
Intel admitted that did crap again, oh... no... just tired of it.


----------



## Maelstorm (Jan 20, 2018)

Well Snurg,

If that's the case, I would go to the media.  Intel's name is already in the mud, a little more just might bring them around.  Especially if it can be proven that Intel is lying to the general public about fixing security issues when in fact they are only giving the updates to select companies/agencies.  The Register, C|NET, Tom's Hardware, and Ars Technica come to mind.

There is only *1* reason why Intel would do this: To allow government surveillance.  The problem, any sufficiently motivated hacker can get in too, which exposes the general public to attacks.

EDIT:

I just did a little research on the memory sinkhole bug.  Turns out there is a ring -1 and -2.  You can remap the APIC to the protected memory address that the ring -2 software uses and redirect it to a GDT of your choosing.  The problem is in the hardware itself and deals with how the logic gates are physically wired together.

An example is if you have a bug in the ALU where it doesn't perform integer multiplication correctly.  That's a gate wiring problem in which a microcode update can't fix it.  The chip must be replaced.  So the memory sinkhole bug is a true hardware bug in the same class as the FDIV bug from the Pentium days.

For a more detailed explanation of what microcode really is, it's the program that runs in the CPU's control unit.  The control unit takes the opcode aka instruction and decodes it into a series of control signals which is then fed to the other units on the chip.  As such, it's *VERY* hardware oriented.  So if the opcode is for an ADD instruction, the control bits for the ALU will be set to a pattern that selects the add output from the ALU.  Wikipedia has a pretty good writeup on it...better than I can do here in the limited space that I have.  Another website that I found also has a basic explanation of how this all works.

In short, you have a datapath and a controller.  The datapath actually performs the calculations and has various hardware resources which performs those operations.  The big one is the ALU.  But you also have the register file, the sign/zero extend unit, various muxes, register forwarding unit and hazard detection unit for pipelined processors,  the 2-bit branch predictors (which are themselves a hardware finite state machine), instruction and data memories, etc....  All of this is wired together and under control of the control unit.  For a pipelined CPU, the control unit is generally just wired logic.  However, you can have a CU that's both wired logic AND microcode programmed.  Simple math/logic instructions are handled by the wired logic of the CU.  More complex instructions are done by the microcode part of the CU.  A modern x86 CPU understands more than 1,000 instructions.  So their control units are incredibly complex.  They are also resource allocation based which adds to that complexity with out-of-order execution units.

I never thought the classes that I have taken on microprocessor and advanced microprocessor design would come in handy so soon.  The term project that I did last semester, CSC-142 Advanced Computer Organization, we built a 16-bit 5 stage pipelined CPU datapath with a RISC control unit from scratch in Verilog.  That was an interesting project to say the least.  With the complexity of the class project still fresh in my mind, I can appreciate the skill of the computer engineers who design these CPUs that we use.  Remember, they are human too and make mistakes like everyone else.


----------



## w0w (Jan 20, 2018)

Maelstorm said:


> they are human too and make mistakes like everyone else.


Wise men learn by other men's mistakes, fools by their own. © 
But yes, there is nothing to do until we buy it from the martians


----------



## Snurg (Jan 20, 2018)

Maelstorm, good writeup!
However this still does not explain why there have been a few microcode updates in the wake of the memory sinkhole thing that were apparently given only to major hardware manufacturers, but not to end-users.

For example, for the 06-2c-02 family-model-stepping processors (i.e. the X and E 36xx and 56xx processors) the out-of-the box microcode version is at maximum 0x1a. As I mentioned, there are HP (and I think Dell and IBM also) BIOS updates that push them up to 0x1e. There are a few other processors which still were quite recent back then and for which microcode fixes were released, but apparently only to big players, not to the public.
These microcodes one has to extract from BIOS update blobs.

This makes me curious.
Because, if it is actually true that the sinkhole thing is unfixable, what then could be the reasons for updating the microcodes for this and apparently a number of other processors also, that allegedly fixed the sinkhole thing, but not to make the fixes available to the broad public?

I am still confused, because this seems contradictory to me.


----------



## ralphbsz (Jan 20, 2018)

Perhaps because the model CPUs with that stepping were only sold to OEMs (such as HP/Dell/IBM/...), and therefore only installed in systems supported by those vendors?  In that case, firmware support should come from those vendors.

Now, whether those vendors chose to release firmware updates for systems that are old enough to have become unsupported is another question.


----------



## w0w (Jan 20, 2018)

ralphbsz said:


> Perhaps because the model CPUs with that stepping were only sold to OEMs (such as HP/Dell/IBM/...


No it's not. I see Snurg already asked the same question on communities.intel.com but it's not answered at least on public. All we have same statement that updates are coming.


----------



## Snurg (Jan 20, 2018)

ralphbsz, good point.
However, this does not seem to be the case with the Westmere-EP class which members mostly share the same family/model/stepping. If it were an OEM-only processor, I am not sure Intel would have listed "recommended customer prices". On the CPU-World pages for these processors for all of these I looked at there are OEM and boxed versions listed.
In addition, there is even an Intel page of the boxed processor I use, so it seems they were available for sale to everybody.


----------



## Dendros (Jan 20, 2018)

I have a question about my CPU, it's an old Core 2 Duo, Intel E6850. From what I understand, only newer Intel CPUs will receive a microcode update. Did I understand correctly? Because if yes, it would mean that my CPU will not be patched against Meltdown/Spectre and I would be forced to migrate to AMD. I really dislike being forced to migrate because of Intel's fault.


----------



## wattie (Jan 20, 2018)




----------



## CraigHB (Jan 20, 2018)

Dendros said:


> I have a question about my CPU, it's an old Core 2 Duo, Intel E6850. From what I understand, only newer Intel CPUs will receive a microcode update. Did I understand correctly? Because if yes, it would mean that my CPU will not be patched against Meltdown/Spectre and I would be forced to migrate to AMD. I really dislike being forced to migrate because of Intel's fault.



I happen to be using a machine with the exact same CPU.  Amazing you can get that much mileage off a computer these days.

I have some experience with micro-controllers and when those have silicon bugs they'll put out an errata sheet.  The only way to fix it is to replace the chip with a newer part.  I wonder if Intel has an errata for that one.  As mentioned, if it's a silicon bug there's no way to fix it other than replacing the processor.  It's unfortunate a bug like that happened, but the silicon side of things is not immune to bugs either.  It will be interesting to see how Intel deals with this.


----------



## Snurg (Jan 21, 2018)

Dendros said:


> ...Core 2 Duo, Intel E6850...


According to this page, your cpu is probably Family 6, Model 15, Stepping 6. There seems to be no microcode file available for this kind of cpu.
But as there are some cpus which exist in varieties you might want to double-check using my small cpupdate program's -i option, which shows you the installed processor's family-model-stepping and the microcode version it is running.


----------



## bookwormep (Jan 21, 2018)

Before more of this thread progresses, I must say Snurg, you need to get an Award for outstanding technical reporting and investigation on this matter! I think I can say on behalf of others reading this that you have done alot of work on this, thank you!


----------



## Dendros (Jan 21, 2018)

Snurg said:


> According to this page, your cpu is probably Family 6, Model 15, Stepping 6. There seems to be no microcode file available for this kind of cpu.
> But as there are some cpus which exist in varieties you might want to double-check using my small cpupdate program's -i option, which shows you the installed processor's family-model-stepping and the microcode version it is running.



I will give it a try, although I'm not too optimistic. How can I run your program?


----------



## gofer_touch (Jan 21, 2018)

And there are larger issues as well, starting with the management engine.


----------



## Snurg (Jan 21, 2018)

w0w said:


> ... but it's not answered at least on public.


At least they promised they'll answer...


Dendros said:


> How can I run your program?


Just download the files into some directory and run `make`. After that there should be an executable `cpupdate` program in the directory. You need to run it as root because as normal user it cannot access the cpuctl devices.
The program requires the cpuctl kernel module being loaded. As this is usually not loaded by default, you'll probably have to `kldload cpuctl`.
When you have done that, you can get the processor information by `./cpupdate -i`.

```
# ./cpupdate -i
Found CPU(s) from Intel
/dev/cpuctl0 identification successful!
Processor Core: 0
ProcessorType:  00
ExtFamily: 00  ExtModel: 02
IntFamily: 06  IntModel: 0C  Stepping: 02
-> Family: 06  Model:    2C
Flags: 1
-> Family: 06  Model:    2C  uCodeRev: 001D
/dev/cpuctl1 identification successful!
Processor Core: 1
<snip>
#
```
It will output the information for every core it found. The reason for that is that one might have multiple processors with different microcode revisions.
The program's usage information is this:

```
# ./cpupdate
Usage: cpupdate [-i] | [-h] | -f <microcodefile> | <-u> <datadir> [-q] [-w]
  -i  show processor information
  -f  show version information of microcode file
  -u  update microcode using microcode files in <datadir>
  -w  write it: without this option cpupdate only simulates updating
  -q  quiet mode
  -h  show this help
#
```
Please be aware that the microcode upload function is still untested. But as it is similar to the devcpu-data microcode uploader, except that several bugs of the latter program have been removed, I think it should work. Will have to extract microcodes for my other PC first to test it.
Aside of some bugs removed (like wrongly set registers, missing safety and compatibility checks) the cpupdate program differs from devcpu-data in that it also works on older FreeBSD versions (possibly even down to 7.2).


.


----------



## Snurg (Jan 21, 2018)

Oops... forgot to upload a header file... Done now.  Thank you Phishfry for alerting me!


gofer_touch said:


> And there are larger issues as well, starting with the management engine.


https://www.csoonline.com/article/3...able-intel-me-backdoor-thanks-to-the-nsa.html


----------



## Dendros (Jan 21, 2018)

Snurg, I have run your program, here is the output:


```
./cpupdate -i
Found CPU(s) from Intel
/dev/cpuctl0 identification successful!
Processor Core: 0
ProcessorType:  00
ExtFamily: 00  ExtModel: 00
IntFamily: 06  IntModel:0F  Stepping: 0B
-> Family: 06  Model:   0F
Flags: 1
-> Family: 06  Model:   0F  uCodeRev: 00B6
/dev/cpuctl1 identification successful!
Processor Core: 1
ProcessorType:  00
ExtFamily: 00  ExtModel: 00
IntFamily: 06  IntModel:0F  Stepping: 0B
-> Family: 06  Model:   0F
Flags: 1
-> Family: 06  Model:   0F  uCodeRev: 00B6
```

What's the verdict?


----------



## Phishfry (Jan 21, 2018)

Dendros  Last microcode update was 2010.
2010/10/03:  06-0f-0b

For a graphical client checkout sysutils/cpu-x
It shows the Family,Model and Stepping.

It is rather bloated though:

```
Number of packages to be installed: 59

The process will require 261 MiB more space.
46 MiB to be downloaded.
```


----------



## Snurg (Jan 21, 2018)

Dendros said:


> ```
> ./cpupdate -i
> <snip>
> IntFamily: 06  IntModel:0F  Stepping: 0B
> ...




```
# ./cpupdate -f microcode-20180108/intel-ucode/06-0f-0b
Update file properties:
Header version 1 (0x1)
Revision 186 (0xba)
Date 10032010
File is to be used for processors with these stats:
<snip>
IntFamily: 06  IntModel: 0F  Stepping: 0B
<snip>
#
```

The microcode update file contains microcode version 0xba, which is more recent than the version 0xb6 in your processor.
However, updating won't fix meltdown due to the age of the microcode update (Oct 3, 2010, as Phishfry correctly stated)...

(I really must rework the output of `cpupdate` to make it readable easier...  it's a hard-to-read mess this way...  Will do that tomorrow and update the github repo)

Edit: Phishfry, I think cpu-x tells nothing more relevant here than you can find yourself with `# dmesg | grep Origin`, but this won't tell you the microcode revision...


----------



## Criosphinx (Jan 21, 2018)

Am I out of luck too?

I have two desktops: i3-530 and i3-3220 running Windows 7 (the 530 dual boots FreeBSD) The last BIOS updates were from 2010 and 2013 respectively. What options do I have? Buy two new systems?

Also I regularly work doing tech support for small business, the majority of the equipment I see are old desktops and laptops with 2nd - 4th generation Intel CPUs. 

I know all of these are legacy cpus but performance is fine for the given use. It's unreasonable to expect that people will just throw away all these perfectly working systems and get new ones.


----------



## Dendros (Jan 21, 2018)

So I'm out of luck. Now I really dislike Intel because I'm forced to make a financiar effort to replace a perfectly working processor and all of that is because they screwed things up.


----------



## Snurg (Jan 21, 2018)

Dendros said:


> So I'm out of luck.


Most or even all of us FreeBSD users are, until 11.2 gets rushed out. It's still not certain whether Intel will ever manage to release working (i.e. not autorebooting etc) microcode updates even for their newest cpus. 
I guess atm our kernel guys are testing the table isolation and trampoline fixes thoroughly so that 11.2 will not be a disaster. 
And I fully agree, Intel is really worth being shown the middle finger up. In future I'll avoid Intel products whereever there exist alternatives.


----------



## Crivens (Jan 21, 2018)

Also from me a big thank you to our herold! Nice work!

As to why a microcode update may solve the sinkhole problem (*that* one got me banging my head into the desk, what in hades had they been thinking?) this requires two instructions to work. One to set up the bad position for the APICs, one to trigger the SM thing. It is highly likely that at least one of them is microcoded, so adding to that microcode program a check if the setup to be done or present is faulty and then tripping some other trap handler would solve it. Even if it is burried deep in the silicon, you can put a road block in front of it. That does not solve it, but it will make abusing it a lot harder. 

Having an interest into the dark arts of verilog and VLSI design for half my life now, I would like to point you lot into the direction here: $SEARCHENGINE "openSPARC T2 verilog source"
Just before oracle bugg..^W bought up SUN, they decided to drop the T2 design to the public. An interesting read, if you can understand it. I did not get deep enough to see if the pipeline is hardcoded or uses microcode (would suspect: NO), but it is a pretty fast CPU and shows what hoops you have to jump trough while juggling burning chainsaws.

Why does AMD not do anything media-wise? I could imagine that they will avoid being seen as unprofessional now, and a "smear campaign" against intel might impact the dealings for funds they might now be doing to be able to buy up some fabs or other stuff from intel. The current CEO there seens to have cached in his chips as far as he could, so I assume the thing is already FUBAR from his point of view.


----------



## CraigHB (Jan 21, 2018)

I had to do some reading about this business.  I usually don't get too worried about security bugs since most of them can be avoided just by being careful about the web sites and emails you deal with.  So yeah The Register being what it is I don't really don't like to quote them, but they do concentrate on the technical side of things.  They said this in their article;



> – the flaw is in the Intel x86-64 hardware, and it appears a microcode update can't address it. It has to be fixed in software at the OS level, or go buy a new processor without the design blunder.



Still reading, came across an article that says this;


> The patches being developed and distributed by operating systems — including microcode updates from Intel — will help a lot, but there are still steps individual developers can take to reduce the risk of their code being exploited.
> 
> http://www.daemonology.net/blog/2018-01-17-some-thoughts-on-spectre-and-meltdown.html


----------



## w0w (Jan 21, 2018)

AFAIK both meltdown and spectre making hackers life much much easier and you can't avoid intrusion just by washing your hands and using respirator, when surfing the web, this thing is on low level like radiation and in this case paranoia is not a disease.


----------



## CraigHB (Jan 21, 2018)

Snurg said:


> Intel is really worth being shown the middle finger up.



Still reading older replies in this thread, one comment I'd like to make.  I'd like to think Intel did not set out to ignore security in the arms race of execution speed.  But I don't know, you'd have to be an Intel engineer to form an opinion of their engineering environment. 

At the least this failure on Intel's part says something about their way of doing business and may warrant avoiding their products, but I'm not convinced malice was there.  On the other hand, it seems this issue has actually been around for a very long time and it wasn't until Google made it public that it came to a head.  In that case you have to wonder why Intel didn't deal with it way back when.  That may in fact be malice on Intel's part.


----------



## Maelstorm (Jan 21, 2018)

ralphbsz said:


> Perhaps because the model CPUs with that stepping were only sold to OEMs (such as HP/Dell/IBM/...), and therefore only installed in systems supported by those vendors?  In that case, firmware support should come from those vendors.



Good point.



Snurg said:


> ralphbsz, good point.
> However, this does not seem to be the case with the Westmere-EP class which members mostly share the same family/model/stepping. If it were an OEM-only processor, I am not sure Intel would have listed "recommended customer prices". On the CPU-World pages for these processors for all of these I looked at there are OEM and boxed versions listed.
> In addition, there is even an Intel page of the boxed processor I use, so it seems they were available for sale to everybody.



A OEM vendor buys lots of CPUs so they may ask for something slightly custom.  The big difference between CPUs destined for OEM and those in boxes is the packaging.  OEMs, more often than not (and definitely with laptops) will solder the CPU directly to the mainboard.  They usually use BGA packaging to do this.  Boxed CPUs are packaged with pins so they can be inserted into sockets.



Crivens said:


> Why does AMD not do anything media-wise? I could imagine that they will avoid being seen as unprofessional now, and a "smear campaign" against intel might impact the dealings for funds they might now be doing to be able to buy up some fabs or other stuff from intel. The current CEO there seens to have cached in his chips as far as he could, so I assume the thing is already FUBAR from his point of view.



It reminds me of those old PC vs. Apple commercials during the 2000's.   It's one of the reasons why I will not buy an Apple computer.  To make disparaging remarks about your competitor like that is completely unprofessional.  If you cannot sell your product on its merits without trashing your competitor at the same time, then perhaps there is a reason why people are not buying your product.

AMD has lead by example on this.  They have made no disparaging remarks against Intel regarding the meltdown bug.  In fact, the only thing that AMD has stated is that their CPUs are immune to meltdown but vulnerable to spectre.  Intel tried to say that AMD CPUs are vulnerable to meltdown in a round-about way which was immediately debunked by AMD.  Intel is just trying to change the narrative because they are looking really bad right now.  Especially since Intel's CEO stated that there will be no recall to replace the defective hardware.  With the up to 65% performance hit, their customers are really, really upset by that.  Which is probably why there is not one, not two, but three class-action lawsuits against Intel right now.

AMD followed Arm's example of publishing errata about which CPUs are affected by what.  Completely professional.  Intel should have done the same but all they did was try to cloud the issue and treat us like we are stupid and don't know anything.  Based on this, and past behavior with the F00F and FDIV bugs, I think that I will be sticking with AMD products for the foreseeable future.

Seriously, the CEO of Intel should be investigated by the SEC for insider trading with the massive stock selloff on November 29, 2017.  Could you make it even more suspicious?


----------



## ralphbsz (Jan 21, 2018)

Crivens said:


> Also from me a big thank you to our herold! Nice work!


Concur.



> Why does AMD not do anything media-wise? ... and a "smear campaign" against intel ...


AMD has been very shaky for a long time now.  They have been through so many deaths, they have learned that they have to be careful.  I happen to know two of their top brass (silicon valley is a small town), and they have a healthy dose of paranoia, which is earned and sensible.  Some of them even spent many years working at Intel.  Intel is also one of their biggest business partners.  It would be pointless and unwise for AMD to go beat up Intel at this point, and anger them.  We can leave that job to the press and the courts.



CraigHB said:


> Still reading older replies in this thread, one comment I'd like to make.  I'd like to think Intel did not set out to ignore security in the arms race of execution speed.  But I don't know, you'd have to be an Intel engineer to form an opinion of their engineering environment.
> 
> At the least this failure on Intel's part says something about their way of doing business and may warrant avoiding their products, but I'm not convinced malice was there.  On the other hand, it seems this issue has actually been around for a very long time and it wasn't until Google made it public that it came to a head.  In that case you have to wonder why Intel didn't deal with it way back when.  That may in fact be malice on Intel's part.


Sadly, I fear that the short-sightedness (at the engineering side) and duplicity and kleptomania (at the executive side) of Intel will be forgotten soon.  The next time Trump tweets something outrageous, this will become old news.  That's really too bad, because that incompetent/duplicity/kleptomania are an outgrowth of Intel's corporate culture, which much of the valley here likes to make fun of (but only in private, over a beer).  What Intel needs is a really big kick in the behind, to change their culture towards engineering excellence and honesty, but that is unlikely to happen.

In Intel's defense: Most other CPUs (of all architectures, not just x86 and x86-64) that use speculative execution have some of the same issues.  The failure is endemic; but Intel as the thought (and market) leader had a special responsibility to "Think".  (I put that term in quotes because it used to be the motto of some long-forgotten computer company.)

Unfortunately, avoiding Intel products is virtually impossible at the large scale.  Individual hobbyists can buy AMD machines for desktops, AMD will probably garner 5-20% market share in the commercial market, and Google/Facebook/... and the federal government are keeping alternative instructions sets and alternative CPU sources alive using artificial life support.  But we have to admit that for now, Intel has won the CPU war, and competition is not their problem.


----------



## Snurg (Jan 21, 2018)

Crivens said:


> As to why a microcode update may solve the sinkhole problem (*that* one got me banging my head into the desk, what in hades had they been thinking?) this requires two instructions to work. One to set up the bad position for the APICs, one to trigger the SM thing. It is highly likely that at least one of them is microcoded, so adding to that microcode program a check if the setup to be done or present is faulty and then tripping some other trap handler would solve it. Even if it is burried deep in the silicon, you can put a road block in front of it. That does not solve it, but it will make abusing it a lot harder.


There is this memory sinkhole PoC code. However, it seems incomplete, as I can see no payload handler included (probably for good reason).
Does anybody know of an open-source test app that can easily tell whether the sinkhole bug (still) works?
If possible, I would like to verify whether the alleged fix actually fixes the issue...


----------



## Maelstorm (Jan 21, 2018)

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.


----------



## ralphbsz (Jan 21, 2018)

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, ...)


----------



## aragats (Jan 21, 2018)

Snurg , there is a small bug in your program, here is a patch
	
	



```
--- 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;
```


----------



## Snurg (Jan 22, 2018)

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.


----------



## aragats (Jan 22, 2018)

Snurg said:


> 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.


----------



## Deleted member 30996 (Jan 22, 2018)

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.


----------



## ralphbsz (Jan 22, 2018)

Trihexagonal said:


> I've looked around and nowhere have I seen Pentium M mentioned as being among those vulnerable.


The Wikipedia page for P6 microarchitecture and Pentium M says that is does speculative execution.  Therefore it should be vulnerable to Spectre.


----------



## Snurg (Jan 22, 2018)

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.


----------



## ralphbsz (Jan 23, 2018)

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.


----------



## Snurg (Jan 23, 2018)

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


----------



## Maelstorm (Jan 23, 2018)

Snurg said:


> 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



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.



ralphbsz said:


> The google news headline says:
> Linux Torvalds declares Intel fix for Meltdown/Spectre "Complete and utter garbage"



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.


----------



## _martin (Jan 23, 2018)

Maelstorm After that google news article, this is worth reading too: https://lkml.org/lkml/2018/1/22/598


----------



## bookwormep (Jan 27, 2018)

Another article with  colorful language:
http://www.zdnet.com/article/linux-and-intel-slowly-hack-their-way-to-a-spectre-patch/


----------



## w0w (Jan 27, 2018)

Interesting, is it possible to implement Google Retpoline solution for Spectre 2 widely, for for all existing OSes?


----------



## sidetone (Jan 29, 2018)

Intel reportedly notified Chinese companies of chip security flaw before the U.S. government
https://techcrunch.com/2018/01/28/i...chip-security-flaw-before-the-u-s-government/


----------



## w0w (Jan 29, 2018)

Stock price saying that nobody cares anymore...


----------



## _martin (Jan 30, 2018)

Since we have this thread here, I think this is a nice reading: https://blog.trailofbits.com/2018/01/30/an-accessible-overview-of-meltdown-and-spectre-part-1/


----------



## w0w (Feb 9, 2018)

https://newsroom.intel.com/news/security-issue-update-progress-continues-firmware-updates/
I hope that this time they did everything right.


----------



## Snurg (Feb 14, 2018)

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.*


----------



## w0w (Feb 17, 2018)

This is official document that was updated several times
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/02/microcode-update-guidance.pdf
It looks optimistic, but there is no trust anymore, after the lies.


----------



## PacketMan (Feb 18, 2018)

I find it ironic that they are still using the marketing phrase "Expereince what's inside".


----------



## Maelstorm (Feb 18, 2018)

PacketMan said:


> I find it ironic that they are still using the marketing phrase "Expereince what's inside".



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.


----------



## Crivens (Feb 19, 2018)

Maelstorm said:


> 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.


----------



## nimmr (Feb 20, 2018)

Snurg said:


> *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.*



Is this for real? Arent they releasing a fix as a patch level for 11.X? (and maybe even 10.X)


----------



## Maelstorm (Feb 20, 2018)

nimmr said:


> 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.


----------



## nimmr (Feb 20, 2018)

Maelstorm said:


> 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.



Yeah I can imagine it being very tricky to fix. Why are you specifically mentioning AMD here? Are the microcode updates from Intel enough? I thought they where withdrawed because they caused reboots.


----------



## Maelstorm (Feb 20, 2018)

nimmr said:


> Yeah I can imagine it being very tricky to fix. Why are you specifically mentioning AMD here? Are the microcode updates from Intel enough? I thought they where withdrawed because they caused reboots.



There are two flaws...   Spectre allows a hosted system running inside a virtual machine to read information from the hypervisor.  This affects pretty much any CPU out there.  Meltdown affects *ONLY* Intel CPUs (and some ARM chips) and it allows arbitrary reading of physical memory.

Of the two, Spectre is the least dangerous, harder to exploit, and can be mitigated by software.  The big concern is web browsers, but most of the vendors have already issued updates.  Meltdown is very dangerous because you can read any physical memory, even memory belonging to the kernel or other processes using a side-channel attack.  It's easily exploitable, but it is also easily remedied by software using kernel page table isolation (KPTI).  This one does not affect AMD CPUs and therefore AMD chips will not suffer the performance hit that Intel chips do.

The Linux folk had a different name for KPTI:  Forcefully Unmap Complete Kernel With Interrupt Trampolines, also known as FUCKWIT, which I think is actually appropriate, but I don't develop for Linux.


----------



## nimmr (Feb 20, 2018)

Pretty hard for us to "be careful". We run PHP websites for customers in jails, and these webapps are regularly hacked by automated scripts because they themselves handle the framework upgrades (I only upgrade the platform stack). This is a nightmare for me to say the least, and having to live with much of this until late june is making it much worse.


----------



## Snurg (Feb 20, 2018)

nimmr

I do not believe that FreeBSD will get more acceptance at hoster companies.
This is indeed a genuine nightmare for every hoster.
Sort of meltdown of another kind.

You might consider migrating to DragonFly BSD, too, just to sleep better the next half year.
The DragonFly chief developer took his job seriously. He fixed the issue in just two days.
After Intel released the new microcodes on Jan 9, he posted an impact analysis next day already.

And when I look at the priorities the FreeBSD developers have, I can just shake my head in disbelief.
(Just see yourself the threads which were closed the last days, as I do not dare to be more explicit in fear of being banned and this thread closed also.)


----------



## Snurg (Feb 22, 2018)

OpenBSD has fix for Meltdown now, too.


----------



## Maelstorm (Feb 23, 2018)

Snurg said:


> OpenBSD has fix for Meltdown now, too.



Interesting.  Perhaps they will commit a diff for FreeBSD?


----------



## Dendros (Feb 23, 2018)

I'm confused about something. How exactly is Meltdown mitigated? From what I read, fixing Meltdown requires a kernel modification (KPTI or its equivalent) and a microcode update from Intel. Did I understand it correctly? I ask because if it's so and coupling this with what someone on this thread said (that Intel will not release microcode updates for older CPUs), it would mean that Meltdown is in fact unmitigable for older CPUs due to missing microcode updates. That's worrying for those that have and use older machines.


----------



## MarcoB (Feb 23, 2018)

Maelstorm said:


> Interesting.  Perhaps they will commit a diff for FreeBSD?


FreeBSD has it since Feb 17th:
https://svnweb.freebsd.org/base?view=revision&revision=329462


----------



## PacketMan (Feb 23, 2018)

MarcoB said:


> FreeBSD has it since Feb 17th:
> https://svnweb.freebsd.org/base?view=revision&revision=329462



Is more work to be done?  I guess the question I should ask is in what release of RELEASE will FreeBSD be fully patched?


----------



## MarcoB (Feb 23, 2018)

That would be 11.2-RELEASE. I wouldn't be suprised if that is released earlier than planned. Or maybe they release a 11.1.1?


----------



## Snurg (Feb 23, 2018)

PacketMan said:


> Is more work to be done?  I guess the question I should ask is in what release of RELEASE will FreeBSD be fully patched?


Yes, there is probably more work to be done. Trampolines have not been mentioned in the revision note, only table isolation.
I guess this is the reason why FreeBSD didn't publicly announce that kernel revision as "fix" like OpenBSD and Linux, where trampolines and retpolines are already implemented.

Furthermore, there are at least two serious bugs in the FreeBSD microcode uploader.
I will do some PRs at the weekend, as my attempt to alert the devs via mailing list was unsuccessful.
There I will also post a patch for the first of these bugs which is very simple (fix use of uninitialized register).
The second bug involves incorrect usage of reserved register bits, would require larger changes in devcpu-data, of which I am not in the mood to do, as devcpu-data is obsolete anyway due to Intel's microcode file format change. Personally I'll use my own updater which uses the new microcode format and doesn't have these bugs.
(As long as Intel still provides the microcodes in the legacy format in addition to the new format, devcpu-data can still be used).


----------



## Maelstorm (Feb 24, 2018)

MarcoB said:


> FreeBSD has it since Feb 17th:
> https://svnweb.freebsd.org/base?view=revision&revision=329462



So why wasn't is announced?  More work to be done?



Snurg said:


> Yes, there is probably more work to be done. Trampolines have not been mentioned in the revision note, only table isolation.
> I guess this is the reason why FreeBSD didn't publicly announce that kernel revision as "fix" like OpenBSD and Linux, where trampolines and retpolines are already implemented.



I guess that answers that question.  The thing about KPTI is that it makes it way harder for an attacker to locate where things are in memory.  The Meltdown bug allows arbitrary reading of physical memory.  By being able to read kernel memory, an attacker can locate the memory space of any process running on the machine.  With that in mind, reading the process memory of something like sshd can reveal crypto keys and such.  For a browser, passwords to your bank account.  Other scenarios come to mind.


----------



## Eric A. Borisch (Mar 6, 2018)

Patch available for _*testing*_ on 11.1-RELEASE:

https://lists.freebsd.org/pipermail/freebsd-stable/2018-March/088526.html


----------



## Eric A. Borisch (Mar 14, 2018)

Available for 11.1: https://www.freebsd.org/security/advisories/FreeBSD-SA-18:03.speculative_execution.asc


----------



## zeissoctopus (Mar 17, 2018)

I use sysutils/cpupdate to update my haswell microcode successfully. However, I discover that the microcode resumes to original version after system reboot.


----------



## Eric A. Borisch (Mar 17, 2018)

zeissoctopus said:


> I use sysutils/cpupdate to update my haswell microcode successfully. However, I discover that the microcode resumes to original version after system reboot.



Yes, that is expected. Try installing sysutils/devcpu-data and adding `microcode_update_enable="YES"` into /etc/rc.conf to have it applied every reboot.


----------



## fernandel (Mar 17, 2018)

zeissoctopus said:


> I use sysutils/cpupdate to update my haswell microcode successfully. However, I discover that the microcode resumes to original version after system reboot.


Put cpupdate_enable="YES" in /etc/rc.conf
or
https://forums.freebsd.org/threads/introducing-cpupdate-a-microcode-tool-for-freebsd.64588/


----------



## zeissoctopus (Mar 17, 2018)

Thank you Erirc and fernandel


----------



## rigoletto@ (Apr 4, 2018)

Intel admits a load of its CPUs have Spectre v2 flaw that can't be fixed.


----------



## joyescape (Apr 4, 2018)

lebarondemerde said:


> Intel admits a load of its CPUs have Spectre v2 flaw that can't be fixed.



Like seriously, they can't do something about it?


----------



## Snurg (Apr 4, 2018)

So there only remain two production candidates (Coffee Lake), all others are either fixed or stopped.
But no new microcode download since Mar 12 yet


----------



## rigoletto@ (Apr 4, 2018)

Gigabyte ThunderXStation is the first ARMv8 workstation PC


----------



## bookwormep (Apr 6, 2018)

lebarondemerde ..you should be given extra vote of thanks as the original author of this post/thread, making us aware of the Intel bug fiasco..and hopefully remedy!


----------



## Crivens (Apr 6, 2018)

To quote a good SciFi:
"There is always hope"
"Only because nobody has figured out how to kill it - yet".

I would not hope too much on a remedy, intel will do what is profitable, not what is right (unless that is equal).


----------



## Deleted member 30996 (Apr 6, 2018)

> Most the CPUs listed above are oldies that went on sale between 2007 and 2011, so it is likely few remain in normal use.
> 
> http://www.theregister.co.uk/2018/04/04/intel_spectre_microcode_updates/



Says who? That encompasses all 8 of my laptops, 7 of which use Intel processors and 4 of those were business lease returns. So maybe less people are using them, but that's spin in my book.


I recently noticed that NoScript, that browser extension I'm always ranting about, is making the following claim on their website:


> NoScript's unique whitelist based pre-emptive script blocking approach prevents exploitation of security vulnerabilities (known, such as Meltdown or Spectre, and even not known yet!) with no loss of functionality...
> 
> https://noscript.net/



I thought I had seen a github page that has a test for the vulnerabilities linked to here, but I don't now. (A lot of those tests you need to allow scripting for.}

While looking for other tests I did see where one claimed:


> To exploit the vulnerabilities, attackers must get you to execute program code on your computer.
> 
> https://www.ashampoo.com/en/usd/pin/1304/security-software/spectre-meltdown-cpu-checker]



So is that really all there is to it? Not allowing scripting to run when you surf the web?

It sounds stupid to even ask if it's that simple, and admittedly I haven't been following this like I should, but I already block scripting.


----------



## JAW (Apr 7, 2018)

Trihexagonal said:


> So is that really all there is to it? Not allowing scripting to run when you surf the web?



Pretty much (and the usual good practices; keeping your system updated, not running random email attachments etc.). The real nasty side of Meltdown was on shared hosting (AWS, Azure, etc), where as a guest you don't know who else might be hosted on the same physical hardware able to run the exploit.


----------



## Deleted member 30996 (Apr 7, 2018)

Well I feel a lot better having all those laptops now. I felt a little foolish at first for having so many potentially vulnerable machines TBH, when it sounded like the sky was falling, but if blocking scripting is all it takes it's business as usual for me.

The Intel Management Engine is a bigger deal than this IMO.


----------



## rufwoof (Apr 7, 2018)

Trihexagonal said:


> but if blocking scripting is all it takes it's business as usual for me.


Seems like a lot of sites however insist of you opening up noscript. Gone are the days of good web site development practice, where you were directed to non java based versions if javascript was disabled.


----------



## Deleted member 30996 (Apr 7, 2018)

More often than not it doesn't take enabling every script that it will list for a site to work. It's being able to recognize which ones and enabling them one by one till you get full functionality. After a while you can tell which are more likely.


----------



## fernandel (Apr 7, 2018)

Today looks like is mine 2.8 GHz Quad Core Intel "Core i7" I7-860 (Lynnfield/Nehalem) (iMac 11,1, 2009) microcode updated. I am using 
sysutils/cpupdate and it works without problems.
Now I have "hw.ibrs_active: 1"


----------



## aragats (Apr 7, 2018)

Do you guys remember this thread?
The original video is unavailable, but it was reposted several times.
Is it related to Meltdown/Spectre?


----------



## PacketMan (Apr 12, 2018)

I'm guessing the class action law-suits that will occur will force Intel to fix more CPUs than they want to, and/or force to issue deeply discounted new CPUs to allow users to replace their not-so-old-not-yet-end-of-life-still-works-fine-for-me-machines at some sort of fair market price where price includes some sort of fair market value of the old machines.  So like either a vehicle recall and/or a buyout vehicle offer.


----------



## Deleted member 30996 (Apr 16, 2018)

Just so it doesn't seem like I am, I'm not discounting the severity or the enormity of the problem. It's that I see it as another in a long list of computer vulnerabilities I already have to deal with, just like everybody else. One that for me as a user falls into a category of threats I'm already addressing.

The aspect of shared hosting applies to me, too, but I have to trust somebody else knows what they're doing on that end of things.


----------



## Crivens (Apr 16, 2018)

I see you still have hope...

Seeing how they are dragging their feet on this, it reminds me of an old saying around here. "They are running so fast you could re-sole their boots while they are at it".

It will be exactly as with vehicles. Nothing will really change, too much campaining money is at stake.


----------



## Deleted member 30996 (Apr 16, 2018)

Crivens said:


> Seeing how they are dragging their feet on this, it reminds me of *an old saying around here*. "They are running so fast you could re-sole their boots while they are at it".
> 
> It will be exactly as with vehicles. Nothing will really change, too much campaining money is at stake.



We have one, too.

"The check is in the mail."

I'll believe it when I see it.


----------



## BSDAppentic3 (Apr 16, 2018)

This seems like if I try to heal a mental illness using psychology.
I don't know if it's ridiculous, if even it's possible, or if is real. It doesn't seems like from another world, but seems like from another level of this reality. A level hard to access.
I mean: we only can access the software through the hardware. Why we can't use the same medium for try to protect ourselves?


----------



## BSDAppentic3 (Apr 16, 2018)

2: Apart of the medium of access, we must think.
As I know, the machines can abstract the information received. The users can do the same, but in a level much more complex.
Depending of the level of knowing, a programmer can fix a bug (for example). But what happens if the trouble is in hardware level?


----------



## Crivens (Apr 16, 2018)

Trihexagonal said:


> We have one, too.
> 
> "The check is in the mail."


There is this joke with the park rangers, two bears and two missing hikers...


----------



## Deleted member 30996 (Apr 16, 2018)

BSDAppentic3 said:


> But what happens if the trouble is in hardware level?



You prevent the bad software intended to exploit it from running, best as possible. The whole idea behind not allowing scripting when you surf the web.


----------



## BSDAppentic3 (Apr 16, 2018)

Trihexagonal said:


> You prevent the bad software intended to exploit it from running, best as possible. The whole idea behind not allowing scripting when you surf the web.


Thanks, but that wasn't what I intended to mean.
I was talking about the fail in Intel/AMD.
I read that only RHEL has a level of security of 5 (which means a lot). I remember it vaguely, so let me try to search the link and translate the article.


----------



## bookwormep (Apr 24, 2018)

Is there a remedy going to be available for i386 architecture on the next FreeBSD-11.2?


----------



## Deleted member 30996 (Apr 24, 2018)

bookwormep said:


> Is there a remedy going to be available for i386 architecture on the next FreeBSD-11.2?



My i386 FreeBSD 11.1-RELEASE-9 box got the kernel update and Intel microcode updates are downloaded with boot.

I don't know if the microcode updates are placebo feel good measures or not, but I don't assume it's any safer now than it was at first and still take steps to mitigate it on my end.


----------



## bookwormep (Apr 25, 2018)

I took advice of post #316, i.e. sysutils/devcpu-data and added code:

```
microcode_update_enable="YES"
```
 to /etc/rc.conf .

I guess the 64-bit architectures will receive the first round of patches and fixes.


----------



## Deleted member 30996 (Apr 25, 2018)

Yes, that's what I have. My i386 uses an Intel Dual Core T2060 @ 1.6GHz and it got a microcode update. All the rest are 64bit Intel Core 2 Duo and they update as well.


----------



## Snurg (May 14, 2018)

Trihexagonal said:


> Yes, that's what I have. My i386 uses an Intel Dual Core T2060 @ 1.6GHz and it got a microcode update. All the rest are 64bit Intel Core 2 Duo and they update as well.


Do you really believe this?
If you were using cpupdate's -f or -d options to show the information hidden in the microcode update file header, you could easily find out the actual update date (not the file timestamp!).
For the T2060:


> File /home/stefan/Downloads/microcode-20180425/intel-ucode/06-0e-0c is single-blobbed
> Blob 1 of 1 headers info:
> SignatureInt:      6EC
> -> Family: 06  Model: 0E  Stepping: 0C
> ...


In case somebody is interested in learning what is actually in the April 25 microcode update files without using cpupdate, I have pastebinned the output of `cpupdate -Ivvd <ucode-dir>`.
Expect some more very soon revelations of things Intel probably hopes not to become too public. Stay tuned.


----------



## Deleted member 30996 (May 14, 2018)

Snurg said:


> Do you really believe this?



No, I don't believe anything they say and already indicated as much:



Trihexagonal said:


> I don't know if the microcode updates are placebo feel good measures or not, but I don't assume it's any safer now than it was at first and still take steps to mitigate it on my end.



It is good to see you back, I wondered how you were doing.

Did you see I changed my x11-wm/fluxbox config so it hopefully doesn't look so much like a Windows desktop?


----------



## PMc (May 24, 2018)

In case You're interested: https://forums.freebsd.org/threads/...acpi-and-crashes-the-system.65990/post-388533


----------



## Crivens (Jun 13, 2018)

Wait, what? That charlie foxtrot is not over..
https://marc.info/?l=openbsd-cvs&m=152818076013158&w=2

I hear AES-NI keeps the keys in that registers. What please would be worse?


----------



## _martin (Jun 22, 2018)

I'm really curious what this will be about: twitter: hyperthreading  ( blackhat TLBleed ).


----------

