Intel bug incoming.

[rigoletto@]

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]

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]

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

(threads merged)

 

[Avernar]

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]

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]

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@]

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

 

[Snurg]

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]

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]

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]

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

 

[Deleted member 30996]

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]

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

 

[Avernar]

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]

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@]

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]

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]

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]

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@]

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]

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]

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]

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]

Lets keep it all in one thread, merged.

 

[PacketMan]

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.