How to check that KPTI is enabled on my Ubuntu?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP








up vote
61
down vote

favorite
20












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.










share|improve this question



























    up vote
    61
    down vote

    favorite
    20












    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.










    share|improve this question

























      up vote
      61
      down vote

      favorite
      20









      up vote
      61
      down vote

      favorite
      20






      20





      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.










      share|improve this question















      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






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Jan 4 at 19:10









      Braiam

      50.2k20131214




      50.2k20131214










      asked Jan 4 at 7:55









      Martin Vysny

      407147




      407147




















          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





          share|improve this answer


















          • 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 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




            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




            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

















          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.






          share|improve this answer






















          • ... 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











          • /var/log/kern.log on 14.04
            – eckes
            Jan 11 at 22:43

















          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.






          share|improve this answer




















          • 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 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

















          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






          share|improve this answer





























            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





            share|improve this answer
















            • 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

















            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.






            share|improve this answer






















            • This method is already mentioned in the top answer
              – wjandrea
              Jan 12 at 21:00










            Your Answer







            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "89"
            ;
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function()
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled)
            StackExchange.using("snippets", function()
            createEditor();
            );

            else
            createEditor();

            );

            function createEditor()
            StackExchange.prepareEditor(
            heartbeatType: 'answer',
            convertImagesToLinks: true,
            noModals: false,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );













             

            draft saved


            draft discarded


















            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






























            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





            share|improve this answer


















            • 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 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




              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




              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














            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





            share|improve this answer


















            • 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 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




              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




              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












            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





            share|improve this answer















            • 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






            share|improve this answer














            share|improve this answer



            share|improve this answer








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




              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




              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












            • 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 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




              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




              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







            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












            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.






            share|improve this answer






















            • ... 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











            • /var/log/kern.log on 14.04
              – eckes
              Jan 11 at 22:43














            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.






            share|improve this answer






















            • ... 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











            • /var/log/kern.log on 14.04
              – eckes
              Jan 11 at 22:43












            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.






            share|improve this answer














            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.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Jan 12 at 2:14

























            answered Jan 4 at 8:33









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











            • /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











            • 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















            ... 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










            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.






            share|improve this answer




















            • 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 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














            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.






            share|improve this answer




















            • 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 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












            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.






            share|improve this answer












            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.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Jan 4 at 8:16









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
















            • 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 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















            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










            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






            share|improve this answer


























              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






              share|improve this answer
























                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






                share|improve this answer














                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







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Jan 10 at 19:15

























                answered Jan 10 at 9:34









                Compte droid

                892




                892




















                    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





                    share|improve this answer
















                    • 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














                    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





                    share|improve this answer
















                    • 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












                    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





                    share|improve this answer












                    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






                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Jan 4 at 8:28









                    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












                    • 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










                    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.






                    share|improve this answer






















                    • This method is already mentioned in the top answer
                      – wjandrea
                      Jan 12 at 21:00














                    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.






                    share|improve this answer






















                    • This method is already mentioned in the top answer
                      – wjandrea
                      Jan 12 at 21:00












                    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.






                    share|improve this answer














                    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.







                    share|improve this answer














                    share|improve this answer



                    share|improve this answer








                    edited Jan 12 at 20:54









                    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
















                    • 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

















                     

                    draft saved


                    draft discarded















































                     


                    draft saved


                    draft discarded














                    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













































































                    Popular posts from this blog

                    pylint3 and pip3 broken

                    Missing snmpget and snmpwalk

                    How to enroll fingerprints to Ubuntu 17.10 with VFS491