Re: [PLUG] The mysterious case of the Linux Page Table Isolation patches

[Rich Freeman <r-plug@thefreemanclan.net>]

On Thu, Jan 4, 2018 at 2:34 PM, Steve Litt <slitt@troubleshooters.com> wrote:
>
> According to
> https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-EPYC-Linux-4.15-Test  ,
> the latest kernel updates enable PTI on AMD "just in case", but because
> AMD is so confident it's not needed, PTI will again be disabled in
> 4.15. For those wanting to repeal the performance hit on their AMD
> earlier, they can put "nopti" in their grub.
>

Correct.  It is in the queue for 4.14.12 as well, and presumably all
the other stable/longterm kernels.  I hear Arch backported it to
4.14.11, and I imagine many other distros will do so as well since it
was accepted upstream.

You can tell from /proc/cpuinfo if the bug flag got enabled on your
CPU by the kernel (the flag has "insecure" in the name).  If it was
and you're on an AMD processor then you could add nopti to the kernel
command line to make it go away.

> I'd extrapolate that to say that anyone with Intel should check their
> grub system and make sure it doesn't contain "nopti".
>

That seems pretty unlikely since the option was just added.  But,
sure, you could check.

>>
>> If you're running Intel then you'll want PTI on in general, and that
>> will cause the performance hit.  It won't hurt virtualization at all
>> other than the general hit.  Note, the penalty might be worse on VMs
>> since both the hypervisor and guest kernel are likely to implement
>> PTI, which means two layers of performance hit on any system call that
>> ends up going out to the hypervisor.
>
> IIRC you can specify your processor in qemu, which means if true I could
> specify an AMD processor and hopefully turn the VM guest's PTI off.
>

Sure, but then the guest kernel is vulnerable to the attack from the
guest userspace.  The host would still be safe from anything in the
guest.  You really do want both layers of protection in a typical case
(if you understand your circumstances and the risk really well you
could choose to disable it on either/both layers).  And if you don't
want PTI in the guest you could just stick nopti on its command line
instead of messing with the CPU type.  If you run everything as root
inside your guest I guess disabling PTI inside the guest wouldn't make
it less secure, since there is no effective kernel/userspace isolation
in the first place.

-- 
Rich
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug