https://git.kernel.org/…/ke…/... sure some of you are working on the patches already, if you are then lets connect cause, I am an ardent researcher for the same as of now.

So here it goes:

As soon as kernel page table isolation(KPTI) bug will be out of embargo, Whatsapp and FB will be flooded with over-night kernel "shikhuritee" experts who will share shitty advices non-stop.

1. The bug under embargo is a side channel attack, which exploits the fact that Intel chips come with speculative execution without proper isolation between user pages and kernel pages. Therefore, with careful scheduling and timing attack will reveal some information from kernel pages, while the code is running in user mode.

In easy terms, if you have a VPS, another person with VPS on same physical server may read memory being used by your VPS, which will result in unwanted data leakage. To make the matter worse, a malicious JS from innocent looking webpage might be (might be, because JS does not provide language constructs for such fine grained control; atleast none that I know as of now) able to read kernel pages, and pawn you real hard, real bad.

2. The bug comes from too much reliance on Tomasulo's algorithm for out-of-order instruction scheduling. It is not yet clear whether the bug can be fixed with a microcode update (and if not, Intel has to fix this in silicon itself). As far as I can dig, there is nothing that hints that this bug is fixable in microcode, which makes the matter much worse. Also according to my understanding a microcode update will be too trivial to fix this kind of a hardware bug.

3. A software-only remedy is possible, and that is being implemented by all major OSs (including our lovely Linux) in kernel space. The patch forces Translation Lookaside Buffer to flush if a context switch happens during a syscall (this is what I understand as of now). The benchmarks are suggesting that slowdown will be somewhere between 5%(best case)-30%(worst case).

4. Regarding point 3, syscalls don't matter much. Only thing that matters is how many times syscalls are called. For example, if you are using read() or write() on 8MB buffers, you won't have too much slowdown; but if you are calling same syscalls once per byte, a heavy performance penalty is guaranteed. All processes are which are I/O heavy are going to suffer (hostings and databases are two common examples).

5. The patch can be disabled in Linux by passing argument to kernel during boot; however it is not advised for pretty much obvious reasons.

6. For gamers: this is not going to affect games (because those are not I/O heavy)

Meltdown: "Meltdown" targeted on desktop chips can read kernel memory from L1D cache, Intel is only affected with this variant. Works on only Intel.

Spectre: Spectre is a hardware vulnerability with implementations of branch prediction that affects modern microprocessors with speculative execution, by allowing malicious processes access to the contents of other programs mapped memory. Works on all chips including Intel/ARM/AMD.

For updates refer the kernel tree: https://git.kernel.org/…/ke…/...

For further details and more chit-chats refer: https://lwn.net/SubscriberLink/...


(Originally written by Adhokshaj Mishra, edited by me. )

  • 11
    I like the image. Aside from that.. I'm not sure what to say.
  • 7
    People from azure contacted us this morning to tell us they were rolling the update already (and thus servers would have to be rebooted). I have to say, the response has been much faster than I thought. I imagined Intel would still take a few days/weeks to test and release the patch to the public
  • 8
    Thank you for the awesome and clear recap!
  • 2
    @endor You are welcome :)
  • 1
    @Gnu-Not-Unix Patches were being pushed in kernel tree for linux since November end :P
  • 2
    You know what's gonna be affected much? Npm!
  • 1
    @Gnu-Not-Unix they knew since june, more than enough time to fix and test
  • 5
    If you have a VM running somewhere check if it's a KVM machine, in that case you're safe from other customers on the same host. (Everything running in your machine is still doomed).
    If it's some shared kernel paravirtualization (Docker, LXC, Linux vserver, OpenVZ) you're double doomed
  • 0
    @Gnu-Not-Unix aMD let it slip that there was a serious bug with Intel when they added a commit to Linux kernel to disable kpti protection on amd. Intel's stock dropped and Intel PR let the beans out of the bag by publishing about the bug and that it affects everything. Google then one-upped them by releasing more detailed information. Originally this was supposed to happen next week but since Intel broke the embargo, everyone has to push their maintainince schedule up therefore, sudden reboots
  • 0
    Are these patches from Intel? As I know Linus Torwalds complained about Intel to sacrifice security for speed in the chip development and the patches have not been created by Intel, they have been created by the kernel devs.
  • 0
    The bug was founed one year ago by Google. And they are gonna release fix next week. Someone leaked the news before embargo.

  • 1
    Thanks for the in depth explanation :)
  • 0
    @marcus5914 Dude the date mentioned on the link is 3rd Jan, 2018.
  • 0
    @Kimmax Dear bro, I have some query regarding virtualization and this attack, do I get a fb or twitter link of you?
  • 0
    @virtu4lgh0st fuck. Sorry I was drunk i read that article.
  • 1
    @virtu4lgh0st write me at somedudewhoaskedfortwitterorfbondevrant@nuernberger.kim

    Jk :P Does not matter what you put in front of the @
  • 0
  • 1
    Thanks for the info! But i have one question how is it possible for javascript to use this vulnerability?
  • 1
    I read about those on TechCrunch and wondered if it's for real. Thanks for clearing it up!
  • 1
    @Jifuna i found a pdf on that, it was with the spectre bug
  • 1
    @Jifuna Yes, it can be implement through JS, and Mozilla has just confirmed that. You need to basically use web-assembly module/asm.js one to implement the assembly code and push it down on client side. ;)
  • 1
    @virtu4lgh0st ah, thanks. Now I understand.
  • 0
    It is funny how, coincidentally, I just finished a course on High Performant Processors at university, which taught us about Tomasulo, speculative execution and so on, which made understanding the issues almost trivial. However, what made me understand it even further is a C snippet that actually exploited spectre, and was able to extract data by just (more or less) timing how long it took to fetch it. In case someone is interested (I did not write it): https://gist.github.com/ErikAugust/...
Add Comment