Intel bug incoming.

SirDice said:
Nobody even knew the bug existed until a few hours ago.
Click to expand...
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.
 
SirDice said:
Nobody even knew the bug existed until a few hours ago.

(threads merged)
Click to expand...

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...
 
SirDice said:
Nobody even knew the bug existed until a few hours ago.
Click to expand...
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.
 
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.
Click to expand...

I was wondering how the OpenBSD 6.2 implementation of KARL would fare against this.
 
Trihexagonal said:
I was wondering how the OpenBSD 6.2 implementation of KARL would fare against this.
Click to expand...
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."
 
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."
Click to expand...

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.
Click to expand...
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.
Click to expand...

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.
 
Trihexagonal said:
Looking at it now I suppose it doesn't make any difference.
Click to expand...

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.
 
Trihexagonal said:
That's why I asked about KARL.
Looking at it now I suppose it doesn't make any difference.
Click to expand...
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.
 
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.
Click to expand...
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.
 
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?
 
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?
 
ralphbsz said:
Tomasulo didn't worry about security, he worried about making the machine reliable, correct, and fast.
Click to expand...
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...
 
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
 
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.
Click to expand...

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.
 
You must log in or register to reply here.
Back
Top