[trendia]

Linux 4.15 and the appropriate modules protect against the attack.

To test, set CONFIG_PAGE_TABLE_ISOLATION=y. That is:

    sudo apt-get build-dep linux
    sudo apt-get install gcc-6-plugin-dev libelf-dev libncurses5-dev
    cd /usr/src
    wget https://git.kernel.org/torvalds/t/linux-4.15-rc7.tar.gz
    tar -xvf linux-4.15-rc7.tar.gz
    cd linux-4.15-rc7
    cp /boot/config-`uname -r` .config
    make CONFIG_PAGE_TABLE_ISOLATION=y deb-pkg

[noobermin]

I have CONFIG_PAGE_TABLE_ISOLATION on. I roll my own kernel and all that.

Trying the kaslr program right now, it's not figuring out the direct map offset and it's probably already been a minute or two. So it works?

EDIT: After 40 minutes, it has attempted all addresses and did not find the direct map offset.

[trendia]

It took about an hour for it to find the offset for me.

I think that the page isolation slows it down, even if it doesn't completely eliminate it.

The second test had something like a 0.05% success rate on my PC, and took over an hour to get a few dozen values read.

After trying this with the new kernel, I started up an AWS instance and ran the tests there. The first test (KASLR) succeeded within a few seconds, and the second test had a 100% success rate (read 1575 values in a few seconds).

[noobermin]

Basically, the first test (kaslr.c) did not even work for me, and it scanned all addresses and wrapped around and started again.

You probably know this (saw you're the person I replied to initially), but for others reading this to check that it's on, "dmesg | grep isolation" should be able to tell you whether the page table isolation is on after you enable it in the kernel.

Given the other tests require the offset, I think I'm safe? I'm going to run it again just to be sure.

[Valmar]

Page Table Isolation has been backported to 4.14.12, so no need to test with the rc.