From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-f198.google.com (mail-qt0-f198.google.com [209.85.216.198]) by kanga.kvack.org (Postfix) with ESMTP id 32E976B5EF4 for ; Sat, 1 Sep 2018 18:33:24 -0400 (EDT) Received: by mail-qt0-f198.google.com with SMTP id 1-v6so20493285qtp.10 for ; Sat, 01 Sep 2018 15:33:24 -0700 (PDT) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id b87-v6sor7090182qkj.54.2018.09.01.15.33.23 for (Google Transport Security); Sat, 01 Sep 2018 15:33:23 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Wes Turner Date: Sat, 1 Sep 2018 18:33:22 -0400 Message-ID: Subject: Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU) Content-Type: multipart/alternative; boundary="00000000000054a9830574d6e505" Sender: owner-linux-mm@kvack.org List-ID: To: Linus Torvalds Cc: "jsteckli@amazon.de" , David Woodhouse , Konrad Rzeszutek Wilk , "juerg.haefliger@hpe.com" , "deepa.srinivasan@oracle.com" , Jim Mattson , Andrew Cooper , Linux Kernel Mailing List , Boris Ostrovsky , linux-mm , Thomas Gleixner , "joao.m.martins@oracle.com" , "pradeep.vincent@oracle.com" , Andi Kleen , Khalid Aziz , "kanth.ghatraju@oracle.com" , Liran Alon , Kees Cook , Kernel Hardening , "chris.hyser@oracle.com" , Tyler Hicks , John Haxby , Jon Masters --00000000000054a9830574d6e505 Content-Type: text/plain; charset="UTF-8" Speaking of pages and slowdowns, is there a better place to ask this question: >>From "'Turning Tables' shared page tables vuln": """ 'New "Turning Tables" Technique Bypasses All Windows Kernel Mitigations' https://www.bleepingcomputer.com/news/security/new-turning-tables-technique-bypasses-all-windows-kernel-mitigations/ > Furthermore, since the concept of page tables is also used by Apple and the Linux project, macOS and Linux are, in theory, also vulnerable to this technique, albeit the researchers have not verified such attacks, as of yet. Slides: https://cdn2.hubspot.net/hubfs/487909/Turning%20(Page)%20Tables_Slides.pdf Naturally, I took notice and decided to forward the latest scary headline to this list to see if this is already being addressed? """ On Saturday, September 1, 2018, Linus Torvalds < torvalds@linux-foundation.org> wrote: > On Fri, Aug 31, 2018 at 12:45 AM Julian Stecklina > wrote: > > > > I've been spending some cycles on the XPFO patch set this week. For the > > patch set as it was posted for v4.13, the performance overhead of > > compiling a Linux kernel is ~40% on x86_64[1]. The overhead comes almost > > completely from TLB flushing. If we can live with stale TLB entries > > allowing temporary access (which I think is reasonable), we can remove > > all TLB flushing (on x86). This reduces the overhead to 2-3% for > > kernel compile. > > I have to say, even 2-3% for a kernel compile sounds absolutely horrendous. > > Kernel bullds are 90% user space at least for me, so a 2-3% slowdown > from a kernel is not some small unnoticeable thing. > > Linus > --00000000000054a9830574d6e505 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Speaking of pages and slowdowns,
is there a better place to ask this qu= estion:

From "'Turning Tables' shared= page tables vuln":

"""
<= div>
'New "Turning Tables" Technique Bypasses All Windows= Kernel Mitigations'

<= /div>
> Furthermore, since the concept of page tables is also used b= y Apple and the Linux project, macOS and Linux are, in theory, also vulnera= ble to this technique, albeit the researchers have not verified such attack= s, as of yet.

Naturally, I took notice and decided to forward the latest sca= ry headline to this list to see if this is already being addressed?
"""

On Saturday, September 1, 2018, Linus Torval= ds <torvalds@linux-foun= dation.org> wrote:
On Fri, Aug 31,= 2018 at 12:45 AM Julian Stecklina <jsteckli@amazon.de> wrote:
>
> I've been spending some cycles on the XPFO patch set this week. Fo= r the
> patch set as it was posted for v4.13, the performance overhead of
> compiling a Linux kernel is ~40% on x86_64[1]. The overhead comes almo= st
> completely from TLB flushing. If we can live with stale TLB entries > allowing temporary access (which I think is reasonable), we can remove=
> all TLB flushing (on x86). This reduces the overhead to 2-3% for
> kernel compile.

I have to say, even 2-3% for a kernel compile sounds absolutely horrendous.=

Kernel bullds are 90% user space at least for me, so a 2-3% slowdown
from a kernel is not some small unnoticeable thing.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Linus
--00000000000054a9830574d6e505--