How to check that KPTI is enabled on my Ubuntu?
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgO9GURib1T8z7lCwjOGLQaGtrueEthgQ8LO42ZX8cOfTqDK4jvDDpKkLFwf2J49kYCMNW7d4ABih_XCb_2UXdq5fPJDkoyg7-8g_YfRUot-XnaXkNYycsNp7lA5_TW9td0FFpLQ2APzKcZ/s1600/1.jpg)
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYQ0N5W1qAOxLP7t7iOM6O6AzbZnkXUy16s7P_CWfOb5UbTQY_aDsc727chyphenhyphen5W4IppVNernMMQeaUFTB_rFzAd95_CDt-tnwN-nBx6JyUp2duGjPaL5-VgNO41AVsA_vu30EJcipdDG409/s400/Clash+Royale+CLAN+TAG%2523URR8PPP.png)
up vote
61
down vote
favorite
The current Meltdown Intel processor vulnerability is currently remedied by having the page table isolation enabled. There is a question how to turn this off: How to disable Page Table Isolation to regain performance lost due to Intel CPU security hole patch?
My question is opposite: is there a way to check on a running system whether the PTI mechanism is effective on the system and thus the system is protected? I'm specifically looking for cat /proc/something
or cat /sys/something
, not checking for kernel version or config parameter or the like.
kernel security
add a comment |Â
up vote
61
down vote
favorite
The current Meltdown Intel processor vulnerability is currently remedied by having the page table isolation enabled. There is a question how to turn this off: How to disable Page Table Isolation to regain performance lost due to Intel CPU security hole patch?
My question is opposite: is there a way to check on a running system whether the PTI mechanism is effective on the system and thus the system is protected? I'm specifically looking for cat /proc/something
or cat /sys/something
, not checking for kernel version or config parameter or the like.
kernel security
add a comment |Â
up vote
61
down vote
favorite
up vote
61
down vote
favorite
The current Meltdown Intel processor vulnerability is currently remedied by having the page table isolation enabled. There is a question how to turn this off: How to disable Page Table Isolation to regain performance lost due to Intel CPU security hole patch?
My question is opposite: is there a way to check on a running system whether the PTI mechanism is effective on the system and thus the system is protected? I'm specifically looking for cat /proc/something
or cat /sys/something
, not checking for kernel version or config parameter or the like.
kernel security
The current Meltdown Intel processor vulnerability is currently remedied by having the page table isolation enabled. There is a question how to turn this off: How to disable Page Table Isolation to regain performance lost due to Intel CPU security hole patch?
My question is opposite: is there a way to check on a running system whether the PTI mechanism is effective on the system and thus the system is protected? I'm specifically looking for cat /proc/something
or cat /sys/something
, not checking for kernel version or config parameter or the like.
kernel security
kernel security
edited Jan 4 at 19:10
Braiam
50.2k20131214
50.2k20131214
asked Jan 4 at 7:55
Martin Vysny
407147
407147
add a comment |Â
add a comment |Â
6 Answers
6
active
oldest
votes
up vote
63
down vote
accepted
Grepping CONFIG_PAGE_TABLE_ISOLATION in kernel config as Raniz's suggested does not help on desktop Ubuntu, but may help on cloud instances:
grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` &&
echo "patched :)" || echo "unpatched :("
You can check with
/proc/cpuinfo
as JonasCz suggested:grep -q "cpu_insecure|cpu_meltdown|kaiser" /proc/cpuinfo && echo "patched :)"
|| echo "unpatched :("
Or from
dmesg
(thanks to Jason Creighton):dmesg | grep -q "Kernel/User page tables isolation: enabled"
&& echo "patched :)" || echo "unpatched :("
You can compile test program from Raphael Carvalho for Meltdown detection:
sudo apt-get install git build-essential
cd /tmp
git clone https://github.com/raphaelsc/Am-I-affected-by-Meltdown.git
cd Am-I-affected-by-Meltdown
make
sudo sh -c "echo 0 > /proc/sys/kernel/kptr_restrict"
./meltdown-checker
on patched system it should end with output
...
so far so good (i.e. meltdown safe) ...
System not affected (take it with a grain of salt though as false negative
may be reported for specific environments; Please consider running it once again).
Check with tool from https://github.com/speed47/spectre-meltdown-checker:
cd /tmp
wget https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
sudo sh /tmp/spectre-meltdown-checker.sh
On patched system it should show the following:
Spectre and Meltdown mitigation detection tool v0.27
Checking for vulnerabilities against live running kernel Linux 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64
...
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
> STATUS: NOT VULNERABLE (PTI mitigates the vulnerability)
Do not install 4.4.0-108-generic on Xenial! It breaks boot/reboot/shutdown/suspend functionality!
Install 4.4.0-109-generic (see USN-3522-3 for details)!
As Robie Basak already wrote, there is a page about Spectre and Meltdown vulnerabilities status in Ubuntu.
Also there are:
- Ubuntu Security bulletin for CVE-2017-5715
- Ubuntu Security bulletin for CVE-2017-5753
- Ubuntu Security bulletin for CVE-2017-5754
3
Updates for Ubuntu are scheduled for Januari 9. They may land earlier but I wouldn't count on it. insights.ubuntu.com/2018/01/04/â¦
â Raniz
Jan 5 at 6:48
4
The "dmesg | grep isolation" type answers are preferable to this, IMO. Some distributions (at least Debian stretch, maybe others) ported PTI to their older kernel, but not the cpu_insecure flag in /proc/cpuinfo. On those systems, looking in the dmesg log is the only way to check, AFAICT.
â Jason Creighton
Jan 6 at 18:03
3
I think thedmesg | grep isolation && echo "patched :)" || echo "unpatched :("
command as listed is unnecessarily dangerous: it doesn't show what line was actually matched, and would also happily print "patched :)" if a random other instance of "isolation" was matched...
â Jaap Eldering
Jan 6 at 20:24
2
I would recommend against the second suggestion (grepping/proc/cpuinfo
for cpu_insecure). If you put that into a script and you have a CPU in the future where the problem is fixed in its microarchitecture,/proc/cpuinfo
will no longer saycpu_insecure
and your script will believe the kernel is unpatched even though it is patched. I would also recommend against the third suggestion, as it's too likely that there might be the wordisolation
in thedmesg
output at some point without it referring to kernel page table isolation.
â blubberdiblub
Jan 7 at 4:28
4
Upon further investigation, all three of these suggestions are broken. Grepping forisolation
will match bothKernel/User page tables isolation: enabled
andKernel/User page tables isolation: disabled on command line
.
â Mark
Jan 7 at 7:31
 |Â
show 10 more comments
up vote
18
down vote
Run the following command :
dmesg | grep 'page tables isolation'
If it displays enabled, then PTI is enabled. If nothing is displayed or you see 'disabled' in the terminal, then PTI is disabled. Ubuntu has not published the patch yet, so it won't display any message.
... or later kernel messages have pushed the bootup messages out of the kernel log buffer. If your kernel prints notices for low-severity stuff like weird network packets, it's common for the boot-time messages to not be part of thedmesg
output. See/var/log/kern.log*
if it goes back far enough to have the boot messages. Ubuntu used to record boot-timedmesg
output to/var/log/dmesg
, but doesn't seem to do that anymore.
â Peter Cordes
Jan 10 at 14:23
On 14.04, I gotdmesg: invalid option -- 'w'
.-H
is also invalid. Removing the flags worked fine for me, as in this answer
â wjandrea
Jan 11 at 20:14
/var/log/kern.log on 14.04
â eckes
Jan 11 at 22:43
add a comment |Â
up vote
12
down vote
You can check with cat /proc/cpuinfo
, if it reports cpu_insecure
under "bugs", then PTI is enabled.
If it's blank (or just does not list cpu_insecure
), then most likely you are running a kernel which has not yet been patched (Ubuntu's hasn't), or you have an AMD processor (for which this will forseeably not be enabled, since they're not vulnerable).
Currently all CPUs are treated as vulnerable in the latest 4.15 kernel.
4.15 is not released yet to the public
â AadhilRF
Jan 4 at 8:25
It is, if you download the latest release candidate from kernel.org and compile it yourself. @Mohammedaadhil
â JonasCz
Jan 4 at 8:28
1
A release candidate isn't a release.
â Ruslan
Jan 4 at 15:36
The article you linked has been updated
â nixpower
Jan 4 at 19:38
2
Kernel 4.14.11 will setcpu_insecure
for any x86 CPU; 4.14.12 and newer will only set it for Intel CPUs (including ones too old or too primitive to be vulnerable. Both will set it even if KPTI is disabled.
â Mark
Jan 7 at 5:38
 |Â
show 2 more comments
up vote
8
down vote
I found this great sh script to test Meltdown/spectre vulnerabilities on your system:
https://github.com/speed47/spectre-meltdown-checker
The script check your system to known Meltdown and spectre patchs on your system to tell you if these vulnerabilities are now mitigated by your OS
add a comment |Â
up vote
2
down vote
You can check /proc/config.gz for CONFIG_PAGE_TABLE_ISOLATION=y
which means that the kernel was compiled with KPTI.
This is on my patched Arch Linux system running 4.14.11-1:
$ zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz
CONFIG_PAGE_TABLE_ISOLATION=y
3
Unfortunately, the config of the currently running kernel in/proc/
is not enabled by default in Ubuntu kernels. The (much less elegant) workaround is grepping/boot/config-$( uname -r )
instead.
â blubberdiblub
Jan 7 at 4:35
5
That only tells you if the kernel was compiled with KPTI, not if KPTI is active (it can be turned off at boot time, and possibly at runtime).
â Mark
Jan 7 at 5:31
If you've explicitly disabled KPTI via kernel command line parameters you shouldn't need to check if it's active or not.
â Raniz
Jan 16 at 7:53
add a comment |Â
up vote
1
down vote
On my AWS Ubuntu 14.04.5 LTS EC2 instance, I ran
grep CONFIG_PAGE_TABLE_ISOLATION /boot/config-$(uname -r)
It should say:
CONFIG_PAGE_TABLE_ISOLATION=y
For update I did:
sudo apt-get update && sudo apt-get install linux-image-generic
I think also this is OK:
sudo apt-get update
sudo apt-get dist-upgrade
To check kernel version:
uname -r
Needs to be 3.13.0-139-generic or newer.
This method is already mentioned in the top answer
â wjandrea
Jan 12 at 21:00
add a comment |Â
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
63
down vote
accepted
Grepping CONFIG_PAGE_TABLE_ISOLATION in kernel config as Raniz's suggested does not help on desktop Ubuntu, but may help on cloud instances:
grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` &&
echo "patched :)" || echo "unpatched :("
You can check with
/proc/cpuinfo
as JonasCz suggested:grep -q "cpu_insecure|cpu_meltdown|kaiser" /proc/cpuinfo && echo "patched :)"
|| echo "unpatched :("
Or from
dmesg
(thanks to Jason Creighton):dmesg | grep -q "Kernel/User page tables isolation: enabled"
&& echo "patched :)" || echo "unpatched :("
You can compile test program from Raphael Carvalho for Meltdown detection:
sudo apt-get install git build-essential
cd /tmp
git clone https://github.com/raphaelsc/Am-I-affected-by-Meltdown.git
cd Am-I-affected-by-Meltdown
make
sudo sh -c "echo 0 > /proc/sys/kernel/kptr_restrict"
./meltdown-checker
on patched system it should end with output
...
so far so good (i.e. meltdown safe) ...
System not affected (take it with a grain of salt though as false negative
may be reported for specific environments; Please consider running it once again).
Check with tool from https://github.com/speed47/spectre-meltdown-checker:
cd /tmp
wget https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
sudo sh /tmp/spectre-meltdown-checker.sh
On patched system it should show the following:
Spectre and Meltdown mitigation detection tool v0.27
Checking for vulnerabilities against live running kernel Linux 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64
...
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
> STATUS: NOT VULNERABLE (PTI mitigates the vulnerability)
Do not install 4.4.0-108-generic on Xenial! It breaks boot/reboot/shutdown/suspend functionality!
Install 4.4.0-109-generic (see USN-3522-3 for details)!
As Robie Basak already wrote, there is a page about Spectre and Meltdown vulnerabilities status in Ubuntu.
Also there are:
- Ubuntu Security bulletin for CVE-2017-5715
- Ubuntu Security bulletin for CVE-2017-5753
- Ubuntu Security bulletin for CVE-2017-5754
3
Updates for Ubuntu are scheduled for Januari 9. They may land earlier but I wouldn't count on it. insights.ubuntu.com/2018/01/04/â¦
â Raniz
Jan 5 at 6:48
4
The "dmesg | grep isolation" type answers are preferable to this, IMO. Some distributions (at least Debian stretch, maybe others) ported PTI to their older kernel, but not the cpu_insecure flag in /proc/cpuinfo. On those systems, looking in the dmesg log is the only way to check, AFAICT.
â Jason Creighton
Jan 6 at 18:03
3
I think thedmesg | grep isolation && echo "patched :)" || echo "unpatched :("
command as listed is unnecessarily dangerous: it doesn't show what line was actually matched, and would also happily print "patched :)" if a random other instance of "isolation" was matched...
â Jaap Eldering
Jan 6 at 20:24
2
I would recommend against the second suggestion (grepping/proc/cpuinfo
for cpu_insecure). If you put that into a script and you have a CPU in the future where the problem is fixed in its microarchitecture,/proc/cpuinfo
will no longer saycpu_insecure
and your script will believe the kernel is unpatched even though it is patched. I would also recommend against the third suggestion, as it's too likely that there might be the wordisolation
in thedmesg
output at some point without it referring to kernel page table isolation.
â blubberdiblub
Jan 7 at 4:28
4
Upon further investigation, all three of these suggestions are broken. Grepping forisolation
will match bothKernel/User page tables isolation: enabled
andKernel/User page tables isolation: disabled on command line
.
â Mark
Jan 7 at 7:31
 |Â
show 10 more comments
up vote
63
down vote
accepted
Grepping CONFIG_PAGE_TABLE_ISOLATION in kernel config as Raniz's suggested does not help on desktop Ubuntu, but may help on cloud instances:
grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` &&
echo "patched :)" || echo "unpatched :("
You can check with
/proc/cpuinfo
as JonasCz suggested:grep -q "cpu_insecure|cpu_meltdown|kaiser" /proc/cpuinfo && echo "patched :)"
|| echo "unpatched :("
Or from
dmesg
(thanks to Jason Creighton):dmesg | grep -q "Kernel/User page tables isolation: enabled"
&& echo "patched :)" || echo "unpatched :("
You can compile test program from Raphael Carvalho for Meltdown detection:
sudo apt-get install git build-essential
cd /tmp
git clone https://github.com/raphaelsc/Am-I-affected-by-Meltdown.git
cd Am-I-affected-by-Meltdown
make
sudo sh -c "echo 0 > /proc/sys/kernel/kptr_restrict"
./meltdown-checker
on patched system it should end with output
...
so far so good (i.e. meltdown safe) ...
System not affected (take it with a grain of salt though as false negative
may be reported for specific environments; Please consider running it once again).
Check with tool from https://github.com/speed47/spectre-meltdown-checker:
cd /tmp
wget https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
sudo sh /tmp/spectre-meltdown-checker.sh
On patched system it should show the following:
Spectre and Meltdown mitigation detection tool v0.27
Checking for vulnerabilities against live running kernel Linux 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64
...
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
> STATUS: NOT VULNERABLE (PTI mitigates the vulnerability)
Do not install 4.4.0-108-generic on Xenial! It breaks boot/reboot/shutdown/suspend functionality!
Install 4.4.0-109-generic (see USN-3522-3 for details)!
As Robie Basak already wrote, there is a page about Spectre and Meltdown vulnerabilities status in Ubuntu.
Also there are:
- Ubuntu Security bulletin for CVE-2017-5715
- Ubuntu Security bulletin for CVE-2017-5753
- Ubuntu Security bulletin for CVE-2017-5754
3
Updates for Ubuntu are scheduled for Januari 9. They may land earlier but I wouldn't count on it. insights.ubuntu.com/2018/01/04/â¦
â Raniz
Jan 5 at 6:48
4
The "dmesg | grep isolation" type answers are preferable to this, IMO. Some distributions (at least Debian stretch, maybe others) ported PTI to their older kernel, but not the cpu_insecure flag in /proc/cpuinfo. On those systems, looking in the dmesg log is the only way to check, AFAICT.
â Jason Creighton
Jan 6 at 18:03
3
I think thedmesg | grep isolation && echo "patched :)" || echo "unpatched :("
command as listed is unnecessarily dangerous: it doesn't show what line was actually matched, and would also happily print "patched :)" if a random other instance of "isolation" was matched...
â Jaap Eldering
Jan 6 at 20:24
2
I would recommend against the second suggestion (grepping/proc/cpuinfo
for cpu_insecure). If you put that into a script and you have a CPU in the future where the problem is fixed in its microarchitecture,/proc/cpuinfo
will no longer saycpu_insecure
and your script will believe the kernel is unpatched even though it is patched. I would also recommend against the third suggestion, as it's too likely that there might be the wordisolation
in thedmesg
output at some point without it referring to kernel page table isolation.
â blubberdiblub
Jan 7 at 4:28
4
Upon further investigation, all three of these suggestions are broken. Grepping forisolation
will match bothKernel/User page tables isolation: enabled
andKernel/User page tables isolation: disabled on command line
.
â Mark
Jan 7 at 7:31
 |Â
show 10 more comments
up vote
63
down vote
accepted
up vote
63
down vote
accepted
Grepping CONFIG_PAGE_TABLE_ISOLATION in kernel config as Raniz's suggested does not help on desktop Ubuntu, but may help on cloud instances:
grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` &&
echo "patched :)" || echo "unpatched :("
You can check with
/proc/cpuinfo
as JonasCz suggested:grep -q "cpu_insecure|cpu_meltdown|kaiser" /proc/cpuinfo && echo "patched :)"
|| echo "unpatched :("
Or from
dmesg
(thanks to Jason Creighton):dmesg | grep -q "Kernel/User page tables isolation: enabled"
&& echo "patched :)" || echo "unpatched :("
You can compile test program from Raphael Carvalho for Meltdown detection:
sudo apt-get install git build-essential
cd /tmp
git clone https://github.com/raphaelsc/Am-I-affected-by-Meltdown.git
cd Am-I-affected-by-Meltdown
make
sudo sh -c "echo 0 > /proc/sys/kernel/kptr_restrict"
./meltdown-checker
on patched system it should end with output
...
so far so good (i.e. meltdown safe) ...
System not affected (take it with a grain of salt though as false negative
may be reported for specific environments; Please consider running it once again).
Check with tool from https://github.com/speed47/spectre-meltdown-checker:
cd /tmp
wget https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
sudo sh /tmp/spectre-meltdown-checker.sh
On patched system it should show the following:
Spectre and Meltdown mitigation detection tool v0.27
Checking for vulnerabilities against live running kernel Linux 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64
...
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
> STATUS: NOT VULNERABLE (PTI mitigates the vulnerability)
Do not install 4.4.0-108-generic on Xenial! It breaks boot/reboot/shutdown/suspend functionality!
Install 4.4.0-109-generic (see USN-3522-3 for details)!
As Robie Basak already wrote, there is a page about Spectre and Meltdown vulnerabilities status in Ubuntu.
Also there are:
- Ubuntu Security bulletin for CVE-2017-5715
- Ubuntu Security bulletin for CVE-2017-5753
- Ubuntu Security bulletin for CVE-2017-5754
Grepping CONFIG_PAGE_TABLE_ISOLATION in kernel config as Raniz's suggested does not help on desktop Ubuntu, but may help on cloud instances:
grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` &&
echo "patched :)" || echo "unpatched :("
You can check with
/proc/cpuinfo
as JonasCz suggested:grep -q "cpu_insecure|cpu_meltdown|kaiser" /proc/cpuinfo && echo "patched :)"
|| echo "unpatched :("
Or from
dmesg
(thanks to Jason Creighton):dmesg | grep -q "Kernel/User page tables isolation: enabled"
&& echo "patched :)" || echo "unpatched :("
You can compile test program from Raphael Carvalho for Meltdown detection:
sudo apt-get install git build-essential
cd /tmp
git clone https://github.com/raphaelsc/Am-I-affected-by-Meltdown.git
cd Am-I-affected-by-Meltdown
make
sudo sh -c "echo 0 > /proc/sys/kernel/kptr_restrict"
./meltdown-checker
on patched system it should end with output
...
so far so good (i.e. meltdown safe) ...
System not affected (take it with a grain of salt though as false negative
may be reported for specific environments; Please consider running it once again).
Check with tool from https://github.com/speed47/spectre-meltdown-checker:
cd /tmp
wget https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
sudo sh /tmp/spectre-meltdown-checker.sh
On patched system it should show the following:
Spectre and Meltdown mitigation detection tool v0.27
Checking for vulnerabilities against live running kernel Linux 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64
...
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
> STATUS: NOT VULNERABLE (PTI mitigates the vulnerability)
Do not install 4.4.0-108-generic on Xenial! It breaks boot/reboot/shutdown/suspend functionality!
Install 4.4.0-109-generic (see USN-3522-3 for details)!
As Robie Basak already wrote, there is a page about Spectre and Meltdown vulnerabilities status in Ubuntu.
Also there are:
- Ubuntu Security bulletin for CVE-2017-5715
- Ubuntu Security bulletin for CVE-2017-5753
- Ubuntu Security bulletin for CVE-2017-5754
edited Jan 12 at 20:47
community wiki
17 revs, 2 users 97%
N0rbert
3
Updates for Ubuntu are scheduled for Januari 9. They may land earlier but I wouldn't count on it. insights.ubuntu.com/2018/01/04/â¦
â Raniz
Jan 5 at 6:48
4
The "dmesg | grep isolation" type answers are preferable to this, IMO. Some distributions (at least Debian stretch, maybe others) ported PTI to their older kernel, but not the cpu_insecure flag in /proc/cpuinfo. On those systems, looking in the dmesg log is the only way to check, AFAICT.
â Jason Creighton
Jan 6 at 18:03
3
I think thedmesg | grep isolation && echo "patched :)" || echo "unpatched :("
command as listed is unnecessarily dangerous: it doesn't show what line was actually matched, and would also happily print "patched :)" if a random other instance of "isolation" was matched...
â Jaap Eldering
Jan 6 at 20:24
2
I would recommend against the second suggestion (grepping/proc/cpuinfo
for cpu_insecure). If you put that into a script and you have a CPU in the future where the problem is fixed in its microarchitecture,/proc/cpuinfo
will no longer saycpu_insecure
and your script will believe the kernel is unpatched even though it is patched. I would also recommend against the third suggestion, as it's too likely that there might be the wordisolation
in thedmesg
output at some point without it referring to kernel page table isolation.
â blubberdiblub
Jan 7 at 4:28
4
Upon further investigation, all three of these suggestions are broken. Grepping forisolation
will match bothKernel/User page tables isolation: enabled
andKernel/User page tables isolation: disabled on command line
.
â Mark
Jan 7 at 7:31
 |Â
show 10 more comments
3
Updates for Ubuntu are scheduled for Januari 9. They may land earlier but I wouldn't count on it. insights.ubuntu.com/2018/01/04/â¦
â Raniz
Jan 5 at 6:48
4
The "dmesg | grep isolation" type answers are preferable to this, IMO. Some distributions (at least Debian stretch, maybe others) ported PTI to their older kernel, but not the cpu_insecure flag in /proc/cpuinfo. On those systems, looking in the dmesg log is the only way to check, AFAICT.
â Jason Creighton
Jan 6 at 18:03
3
I think thedmesg | grep isolation && echo "patched :)" || echo "unpatched :("
command as listed is unnecessarily dangerous: it doesn't show what line was actually matched, and would also happily print "patched :)" if a random other instance of "isolation" was matched...
â Jaap Eldering
Jan 6 at 20:24
2
I would recommend against the second suggestion (grepping/proc/cpuinfo
for cpu_insecure). If you put that into a script and you have a CPU in the future where the problem is fixed in its microarchitecture,/proc/cpuinfo
will no longer saycpu_insecure
and your script will believe the kernel is unpatched even though it is patched. I would also recommend against the third suggestion, as it's too likely that there might be the wordisolation
in thedmesg
output at some point without it referring to kernel page table isolation.
â blubberdiblub
Jan 7 at 4:28
4
Upon further investigation, all three of these suggestions are broken. Grepping forisolation
will match bothKernel/User page tables isolation: enabled
andKernel/User page tables isolation: disabled on command line
.
â Mark
Jan 7 at 7:31
3
3
Updates for Ubuntu are scheduled for Januari 9. They may land earlier but I wouldn't count on it. insights.ubuntu.com/2018/01/04/â¦
â Raniz
Jan 5 at 6:48
Updates for Ubuntu are scheduled for Januari 9. They may land earlier but I wouldn't count on it. insights.ubuntu.com/2018/01/04/â¦
â Raniz
Jan 5 at 6:48
4
4
The "dmesg | grep isolation" type answers are preferable to this, IMO. Some distributions (at least Debian stretch, maybe others) ported PTI to their older kernel, but not the cpu_insecure flag in /proc/cpuinfo. On those systems, looking in the dmesg log is the only way to check, AFAICT.
â Jason Creighton
Jan 6 at 18:03
The "dmesg | grep isolation" type answers are preferable to this, IMO. Some distributions (at least Debian stretch, maybe others) ported PTI to their older kernel, but not the cpu_insecure flag in /proc/cpuinfo. On those systems, looking in the dmesg log is the only way to check, AFAICT.
â Jason Creighton
Jan 6 at 18:03
3
3
I think the
dmesg | grep isolation && echo "patched :)" || echo "unpatched :("
command as listed is unnecessarily dangerous: it doesn't show what line was actually matched, and would also happily print "patched :)" if a random other instance of "isolation" was matched...â Jaap Eldering
Jan 6 at 20:24
I think the
dmesg | grep isolation && echo "patched :)" || echo "unpatched :("
command as listed is unnecessarily dangerous: it doesn't show what line was actually matched, and would also happily print "patched :)" if a random other instance of "isolation" was matched...â Jaap Eldering
Jan 6 at 20:24
2
2
I would recommend against the second suggestion (grepping
/proc/cpuinfo
for cpu_insecure). If you put that into a script and you have a CPU in the future where the problem is fixed in its microarchitecture, /proc/cpuinfo
will no longer say cpu_insecure
and your script will believe the kernel is unpatched even though it is patched. I would also recommend against the third suggestion, as it's too likely that there might be the word isolation
in the dmesg
output at some point without it referring to kernel page table isolation.â blubberdiblub
Jan 7 at 4:28
I would recommend against the second suggestion (grepping
/proc/cpuinfo
for cpu_insecure). If you put that into a script and you have a CPU in the future where the problem is fixed in its microarchitecture, /proc/cpuinfo
will no longer say cpu_insecure
and your script will believe the kernel is unpatched even though it is patched. I would also recommend against the third suggestion, as it's too likely that there might be the word isolation
in the dmesg
output at some point without it referring to kernel page table isolation.â blubberdiblub
Jan 7 at 4:28
4
4
Upon further investigation, all three of these suggestions are broken. Grepping for
isolation
will match both Kernel/User page tables isolation: enabled
and Kernel/User page tables isolation: disabled on command line
.â Mark
Jan 7 at 7:31
Upon further investigation, all three of these suggestions are broken. Grepping for
isolation
will match both Kernel/User page tables isolation: enabled
and Kernel/User page tables isolation: disabled on command line
.â Mark
Jan 7 at 7:31
 |Â
show 10 more comments
up vote
18
down vote
Run the following command :
dmesg | grep 'page tables isolation'
If it displays enabled, then PTI is enabled. If nothing is displayed or you see 'disabled' in the terminal, then PTI is disabled. Ubuntu has not published the patch yet, so it won't display any message.
... or later kernel messages have pushed the bootup messages out of the kernel log buffer. If your kernel prints notices for low-severity stuff like weird network packets, it's common for the boot-time messages to not be part of thedmesg
output. See/var/log/kern.log*
if it goes back far enough to have the boot messages. Ubuntu used to record boot-timedmesg
output to/var/log/dmesg
, but doesn't seem to do that anymore.
â Peter Cordes
Jan 10 at 14:23
On 14.04, I gotdmesg: invalid option -- 'w'
.-H
is also invalid. Removing the flags worked fine for me, as in this answer
â wjandrea
Jan 11 at 20:14
/var/log/kern.log on 14.04
â eckes
Jan 11 at 22:43
add a comment |Â
up vote
18
down vote
Run the following command :
dmesg | grep 'page tables isolation'
If it displays enabled, then PTI is enabled. If nothing is displayed or you see 'disabled' in the terminal, then PTI is disabled. Ubuntu has not published the patch yet, so it won't display any message.
... or later kernel messages have pushed the bootup messages out of the kernel log buffer. If your kernel prints notices for low-severity stuff like weird network packets, it's common for the boot-time messages to not be part of thedmesg
output. See/var/log/kern.log*
if it goes back far enough to have the boot messages. Ubuntu used to record boot-timedmesg
output to/var/log/dmesg
, but doesn't seem to do that anymore.
â Peter Cordes
Jan 10 at 14:23
On 14.04, I gotdmesg: invalid option -- 'w'
.-H
is also invalid. Removing the flags worked fine for me, as in this answer
â wjandrea
Jan 11 at 20:14
/var/log/kern.log on 14.04
â eckes
Jan 11 at 22:43
add a comment |Â
up vote
18
down vote
up vote
18
down vote
Run the following command :
dmesg | grep 'page tables isolation'
If it displays enabled, then PTI is enabled. If nothing is displayed or you see 'disabled' in the terminal, then PTI is disabled. Ubuntu has not published the patch yet, so it won't display any message.
Run the following command :
dmesg | grep 'page tables isolation'
If it displays enabled, then PTI is enabled. If nothing is displayed or you see 'disabled' in the terminal, then PTI is disabled. Ubuntu has not published the patch yet, so it won't display any message.
edited Jan 12 at 2:14
answered Jan 4 at 8:33
![](https://lh4.googleusercontent.com/-SfOclufg0ko/AAAAAAAAAAI/AAAAAAAAAOk/L_nY3mKWvvw/photo.jpg?sz=32)
![](https://lh4.googleusercontent.com/-SfOclufg0ko/AAAAAAAAAAI/AAAAAAAAAOk/L_nY3mKWvvw/photo.jpg?sz=32)
AadhilRF
39118
39118
... or later kernel messages have pushed the bootup messages out of the kernel log buffer. If your kernel prints notices for low-severity stuff like weird network packets, it's common for the boot-time messages to not be part of thedmesg
output. See/var/log/kern.log*
if it goes back far enough to have the boot messages. Ubuntu used to record boot-timedmesg
output to/var/log/dmesg
, but doesn't seem to do that anymore.
â Peter Cordes
Jan 10 at 14:23
On 14.04, I gotdmesg: invalid option -- 'w'
.-H
is also invalid. Removing the flags worked fine for me, as in this answer
â wjandrea
Jan 11 at 20:14
/var/log/kern.log on 14.04
â eckes
Jan 11 at 22:43
add a comment |Â
... or later kernel messages have pushed the bootup messages out of the kernel log buffer. If your kernel prints notices for low-severity stuff like weird network packets, it's common for the boot-time messages to not be part of thedmesg
output. See/var/log/kern.log*
if it goes back far enough to have the boot messages. Ubuntu used to record boot-timedmesg
output to/var/log/dmesg
, but doesn't seem to do that anymore.
â Peter Cordes
Jan 10 at 14:23
On 14.04, I gotdmesg: invalid option -- 'w'
.-H
is also invalid. Removing the flags worked fine for me, as in this answer
â wjandrea
Jan 11 at 20:14
/var/log/kern.log on 14.04
â eckes
Jan 11 at 22:43
... or later kernel messages have pushed the bootup messages out of the kernel log buffer. If your kernel prints notices for low-severity stuff like weird network packets, it's common for the boot-time messages to not be part of the
dmesg
output. See /var/log/kern.log*
if it goes back far enough to have the boot messages. Ubuntu used to record boot-time dmesg
output to /var/log/dmesg
, but doesn't seem to do that anymore.â Peter Cordes
Jan 10 at 14:23
... or later kernel messages have pushed the bootup messages out of the kernel log buffer. If your kernel prints notices for low-severity stuff like weird network packets, it's common for the boot-time messages to not be part of the
dmesg
output. See /var/log/kern.log*
if it goes back far enough to have the boot messages. Ubuntu used to record boot-time dmesg
output to /var/log/dmesg
, but doesn't seem to do that anymore.â Peter Cordes
Jan 10 at 14:23
On 14.04, I got
dmesg: invalid option -- 'w'
. -H
is also invalid. Removing the flags worked fine for me, as in this answerâ wjandrea
Jan 11 at 20:14
On 14.04, I got
dmesg: invalid option -- 'w'
. -H
is also invalid. Removing the flags worked fine for me, as in this answerâ wjandrea
Jan 11 at 20:14
/var/log/kern.log on 14.04
â eckes
Jan 11 at 22:43
/var/log/kern.log on 14.04
â eckes
Jan 11 at 22:43
add a comment |Â
up vote
12
down vote
You can check with cat /proc/cpuinfo
, if it reports cpu_insecure
under "bugs", then PTI is enabled.
If it's blank (or just does not list cpu_insecure
), then most likely you are running a kernel which has not yet been patched (Ubuntu's hasn't), or you have an AMD processor (for which this will forseeably not be enabled, since they're not vulnerable).
Currently all CPUs are treated as vulnerable in the latest 4.15 kernel.
4.15 is not released yet to the public
â AadhilRF
Jan 4 at 8:25
It is, if you download the latest release candidate from kernel.org and compile it yourself. @Mohammedaadhil
â JonasCz
Jan 4 at 8:28
1
A release candidate isn't a release.
â Ruslan
Jan 4 at 15:36
The article you linked has been updated
â nixpower
Jan 4 at 19:38
2
Kernel 4.14.11 will setcpu_insecure
for any x86 CPU; 4.14.12 and newer will only set it for Intel CPUs (including ones too old or too primitive to be vulnerable. Both will set it even if KPTI is disabled.
â Mark
Jan 7 at 5:38
 |Â
show 2 more comments
up vote
12
down vote
You can check with cat /proc/cpuinfo
, if it reports cpu_insecure
under "bugs", then PTI is enabled.
If it's blank (or just does not list cpu_insecure
), then most likely you are running a kernel which has not yet been patched (Ubuntu's hasn't), or you have an AMD processor (for which this will forseeably not be enabled, since they're not vulnerable).
Currently all CPUs are treated as vulnerable in the latest 4.15 kernel.
4.15 is not released yet to the public
â AadhilRF
Jan 4 at 8:25
It is, if you download the latest release candidate from kernel.org and compile it yourself. @Mohammedaadhil
â JonasCz
Jan 4 at 8:28
1
A release candidate isn't a release.
â Ruslan
Jan 4 at 15:36
The article you linked has been updated
â nixpower
Jan 4 at 19:38
2
Kernel 4.14.11 will setcpu_insecure
for any x86 CPU; 4.14.12 and newer will only set it for Intel CPUs (including ones too old or too primitive to be vulnerable. Both will set it even if KPTI is disabled.
â Mark
Jan 7 at 5:38
 |Â
show 2 more comments
up vote
12
down vote
up vote
12
down vote
You can check with cat /proc/cpuinfo
, if it reports cpu_insecure
under "bugs", then PTI is enabled.
If it's blank (or just does not list cpu_insecure
), then most likely you are running a kernel which has not yet been patched (Ubuntu's hasn't), or you have an AMD processor (for which this will forseeably not be enabled, since they're not vulnerable).
Currently all CPUs are treated as vulnerable in the latest 4.15 kernel.
You can check with cat /proc/cpuinfo
, if it reports cpu_insecure
under "bugs", then PTI is enabled.
If it's blank (or just does not list cpu_insecure
), then most likely you are running a kernel which has not yet been patched (Ubuntu's hasn't), or you have an AMD processor (for which this will forseeably not be enabled, since they're not vulnerable).
Currently all CPUs are treated as vulnerable in the latest 4.15 kernel.
answered Jan 4 at 8:16
![](https://i.stack.imgur.com/Qmumx.png?s=32&g=1)
![](https://i.stack.imgur.com/Qmumx.png?s=32&g=1)
JonasCz
3,2431133
3,2431133
4.15 is not released yet to the public
â AadhilRF
Jan 4 at 8:25
It is, if you download the latest release candidate from kernel.org and compile it yourself. @Mohammedaadhil
â JonasCz
Jan 4 at 8:28
1
A release candidate isn't a release.
â Ruslan
Jan 4 at 15:36
The article you linked has been updated
â nixpower
Jan 4 at 19:38
2
Kernel 4.14.11 will setcpu_insecure
for any x86 CPU; 4.14.12 and newer will only set it for Intel CPUs (including ones too old or too primitive to be vulnerable. Both will set it even if KPTI is disabled.
â Mark
Jan 7 at 5:38
 |Â
show 2 more comments
4.15 is not released yet to the public
â AadhilRF
Jan 4 at 8:25
It is, if you download the latest release candidate from kernel.org and compile it yourself. @Mohammedaadhil
â JonasCz
Jan 4 at 8:28
1
A release candidate isn't a release.
â Ruslan
Jan 4 at 15:36
The article you linked has been updated
â nixpower
Jan 4 at 19:38
2
Kernel 4.14.11 will setcpu_insecure
for any x86 CPU; 4.14.12 and newer will only set it for Intel CPUs (including ones too old or too primitive to be vulnerable. Both will set it even if KPTI is disabled.
â Mark
Jan 7 at 5:38
4.15 is not released yet to the public
â AadhilRF
Jan 4 at 8:25
4.15 is not released yet to the public
â AadhilRF
Jan 4 at 8:25
It is, if you download the latest release candidate from kernel.org and compile it yourself. @Mohammedaadhil
â JonasCz
Jan 4 at 8:28
It is, if you download the latest release candidate from kernel.org and compile it yourself. @Mohammedaadhil
â JonasCz
Jan 4 at 8:28
1
1
A release candidate isn't a release.
â Ruslan
Jan 4 at 15:36
A release candidate isn't a release.
â Ruslan
Jan 4 at 15:36
The article you linked has been updated
â nixpower
Jan 4 at 19:38
The article you linked has been updated
â nixpower
Jan 4 at 19:38
2
2
Kernel 4.14.11 will set
cpu_insecure
for any x86 CPU; 4.14.12 and newer will only set it for Intel CPUs (including ones too old or too primitive to be vulnerable. Both will set it even if KPTI is disabled.â Mark
Jan 7 at 5:38
Kernel 4.14.11 will set
cpu_insecure
for any x86 CPU; 4.14.12 and newer will only set it for Intel CPUs (including ones too old or too primitive to be vulnerable. Both will set it even if KPTI is disabled.â Mark
Jan 7 at 5:38
 |Â
show 2 more comments
up vote
8
down vote
I found this great sh script to test Meltdown/spectre vulnerabilities on your system:
https://github.com/speed47/spectre-meltdown-checker
The script check your system to known Meltdown and spectre patchs on your system to tell you if these vulnerabilities are now mitigated by your OS
add a comment |Â
up vote
8
down vote
I found this great sh script to test Meltdown/spectre vulnerabilities on your system:
https://github.com/speed47/spectre-meltdown-checker
The script check your system to known Meltdown and spectre patchs on your system to tell you if these vulnerabilities are now mitigated by your OS
add a comment |Â
up vote
8
down vote
up vote
8
down vote
I found this great sh script to test Meltdown/spectre vulnerabilities on your system:
https://github.com/speed47/spectre-meltdown-checker
The script check your system to known Meltdown and spectre patchs on your system to tell you if these vulnerabilities are now mitigated by your OS
I found this great sh script to test Meltdown/spectre vulnerabilities on your system:
https://github.com/speed47/spectre-meltdown-checker
The script check your system to known Meltdown and spectre patchs on your system to tell you if these vulnerabilities are now mitigated by your OS
edited Jan 10 at 19:15
answered Jan 10 at 9:34
Compte droid
892
892
add a comment |Â
add a comment |Â
up vote
2
down vote
You can check /proc/config.gz for CONFIG_PAGE_TABLE_ISOLATION=y
which means that the kernel was compiled with KPTI.
This is on my patched Arch Linux system running 4.14.11-1:
$ zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz
CONFIG_PAGE_TABLE_ISOLATION=y
3
Unfortunately, the config of the currently running kernel in/proc/
is not enabled by default in Ubuntu kernels. The (much less elegant) workaround is grepping/boot/config-$( uname -r )
instead.
â blubberdiblub
Jan 7 at 4:35
5
That only tells you if the kernel was compiled with KPTI, not if KPTI is active (it can be turned off at boot time, and possibly at runtime).
â Mark
Jan 7 at 5:31
If you've explicitly disabled KPTI via kernel command line parameters you shouldn't need to check if it's active or not.
â Raniz
Jan 16 at 7:53
add a comment |Â
up vote
2
down vote
You can check /proc/config.gz for CONFIG_PAGE_TABLE_ISOLATION=y
which means that the kernel was compiled with KPTI.
This is on my patched Arch Linux system running 4.14.11-1:
$ zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz
CONFIG_PAGE_TABLE_ISOLATION=y
3
Unfortunately, the config of the currently running kernel in/proc/
is not enabled by default in Ubuntu kernels. The (much less elegant) workaround is grepping/boot/config-$( uname -r )
instead.
â blubberdiblub
Jan 7 at 4:35
5
That only tells you if the kernel was compiled with KPTI, not if KPTI is active (it can be turned off at boot time, and possibly at runtime).
â Mark
Jan 7 at 5:31
If you've explicitly disabled KPTI via kernel command line parameters you shouldn't need to check if it's active or not.
â Raniz
Jan 16 at 7:53
add a comment |Â
up vote
2
down vote
up vote
2
down vote
You can check /proc/config.gz for CONFIG_PAGE_TABLE_ISOLATION=y
which means that the kernel was compiled with KPTI.
This is on my patched Arch Linux system running 4.14.11-1:
$ zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz
CONFIG_PAGE_TABLE_ISOLATION=y
You can check /proc/config.gz for CONFIG_PAGE_TABLE_ISOLATION=y
which means that the kernel was compiled with KPTI.
This is on my patched Arch Linux system running 4.14.11-1:
$ zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz
CONFIG_PAGE_TABLE_ISOLATION=y
answered Jan 4 at 8:28
![](https://i.stack.imgur.com/AQ3sF.jpg?s=32&g=1)
![](https://i.stack.imgur.com/AQ3sF.jpg?s=32&g=1)
Raniz
31425
31425
3
Unfortunately, the config of the currently running kernel in/proc/
is not enabled by default in Ubuntu kernels. The (much less elegant) workaround is grepping/boot/config-$( uname -r )
instead.
â blubberdiblub
Jan 7 at 4:35
5
That only tells you if the kernel was compiled with KPTI, not if KPTI is active (it can be turned off at boot time, and possibly at runtime).
â Mark
Jan 7 at 5:31
If you've explicitly disabled KPTI via kernel command line parameters you shouldn't need to check if it's active or not.
â Raniz
Jan 16 at 7:53
add a comment |Â
3
Unfortunately, the config of the currently running kernel in/proc/
is not enabled by default in Ubuntu kernels. The (much less elegant) workaround is grepping/boot/config-$( uname -r )
instead.
â blubberdiblub
Jan 7 at 4:35
5
That only tells you if the kernel was compiled with KPTI, not if KPTI is active (it can be turned off at boot time, and possibly at runtime).
â Mark
Jan 7 at 5:31
If you've explicitly disabled KPTI via kernel command line parameters you shouldn't need to check if it's active or not.
â Raniz
Jan 16 at 7:53
3
3
Unfortunately, the config of the currently running kernel in
/proc/
is not enabled by default in Ubuntu kernels. The (much less elegant) workaround is grepping /boot/config-$( uname -r )
instead.â blubberdiblub
Jan 7 at 4:35
Unfortunately, the config of the currently running kernel in
/proc/
is not enabled by default in Ubuntu kernels. The (much less elegant) workaround is grepping /boot/config-$( uname -r )
instead.â blubberdiblub
Jan 7 at 4:35
5
5
That only tells you if the kernel was compiled with KPTI, not if KPTI is active (it can be turned off at boot time, and possibly at runtime).
â Mark
Jan 7 at 5:31
That only tells you if the kernel was compiled with KPTI, not if KPTI is active (it can be turned off at boot time, and possibly at runtime).
â Mark
Jan 7 at 5:31
If you've explicitly disabled KPTI via kernel command line parameters you shouldn't need to check if it's active or not.
â Raniz
Jan 16 at 7:53
If you've explicitly disabled KPTI via kernel command line parameters you shouldn't need to check if it's active or not.
â Raniz
Jan 16 at 7:53
add a comment |Â
up vote
1
down vote
On my AWS Ubuntu 14.04.5 LTS EC2 instance, I ran
grep CONFIG_PAGE_TABLE_ISOLATION /boot/config-$(uname -r)
It should say:
CONFIG_PAGE_TABLE_ISOLATION=y
For update I did:
sudo apt-get update && sudo apt-get install linux-image-generic
I think also this is OK:
sudo apt-get update
sudo apt-get dist-upgrade
To check kernel version:
uname -r
Needs to be 3.13.0-139-generic or newer.
This method is already mentioned in the top answer
â wjandrea
Jan 12 at 21:00
add a comment |Â
up vote
1
down vote
On my AWS Ubuntu 14.04.5 LTS EC2 instance, I ran
grep CONFIG_PAGE_TABLE_ISOLATION /boot/config-$(uname -r)
It should say:
CONFIG_PAGE_TABLE_ISOLATION=y
For update I did:
sudo apt-get update && sudo apt-get install linux-image-generic
I think also this is OK:
sudo apt-get update
sudo apt-get dist-upgrade
To check kernel version:
uname -r
Needs to be 3.13.0-139-generic or newer.
This method is already mentioned in the top answer
â wjandrea
Jan 12 at 21:00
add a comment |Â
up vote
1
down vote
up vote
1
down vote
On my AWS Ubuntu 14.04.5 LTS EC2 instance, I ran
grep CONFIG_PAGE_TABLE_ISOLATION /boot/config-$(uname -r)
It should say:
CONFIG_PAGE_TABLE_ISOLATION=y
For update I did:
sudo apt-get update && sudo apt-get install linux-image-generic
I think also this is OK:
sudo apt-get update
sudo apt-get dist-upgrade
To check kernel version:
uname -r
Needs to be 3.13.0-139-generic or newer.
On my AWS Ubuntu 14.04.5 LTS EC2 instance, I ran
grep CONFIG_PAGE_TABLE_ISOLATION /boot/config-$(uname -r)
It should say:
CONFIG_PAGE_TABLE_ISOLATION=y
For update I did:
sudo apt-get update && sudo apt-get install linux-image-generic
I think also this is OK:
sudo apt-get update
sudo apt-get dist-upgrade
To check kernel version:
uname -r
Needs to be 3.13.0-139-generic or newer.
edited Jan 12 at 20:54
![](https://i.stack.imgur.com/eVuAv.png?s=32&g=1)
![](https://i.stack.imgur.com/eVuAv.png?s=32&g=1)
wjandrea
7,34042256
7,34042256
answered Jan 12 at 10:17
drKreso
1114
1114
This method is already mentioned in the top answer
â wjandrea
Jan 12 at 21:00
add a comment |Â
This method is already mentioned in the top answer
â wjandrea
Jan 12 at 21:00
This method is already mentioned in the top answer
â wjandrea
Jan 12 at 21:00
This method is already mentioned in the top answer
â wjandrea
Jan 12 at 21:00
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f992137%2fhow-to-check-that-kpti-is-enabled-on-my-ubuntu%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password