linux-kernel - Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ciirm8a7p3alos.fsf@u54ee758033e858cfa736.ant.amazon.com>
Date:   Thu, 30 Aug 2018 18:00:51 +0200
From:   Julian Stecklina <jsteckli@...zon.de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     David Woodhouse <dwmw@...zon.co.uk>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        juerg.haefliger@....com, deepa.srinivasan@...cle.com,
        Jim Mattson <jmattson@...gle.com>,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        linux-mm <linux-mm@...ck.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        joao.m.martins@...cle.com, pradeep.vincent@...cle.com,
        Andi Kleen <ak@...ux.intel.com>,
        Khalid Aziz <khalid.aziz@...cle.com>,
        kanth.ghatraju@...cle.com, Liran Alon <liran.alon@...cle.com>,
        Kees Cook <keescook@...gle.com>,
        Kernel Hardening <kernel-hardening@...ts.openwall.com>,
        chris.hyser@...cle.com, Tyler Hicks <tyhicks@...onical.com>,
        John Haxby <john.haxby@...cle.com>,
        Jon Masters <jcm@...hat.com>
Subject: Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU)

Hey everyone,

On Mon, 20 Aug 2018 15:27 Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> On Mon, Aug 20, 2018 at 3:02 PM Woodhouse, David <dwmw@...zon.co.uk> wrote:
>>
>> It's the *kernel* we don't want being able to access those pages,
>> because of the multitude of unfixable cache load gadgets.
>
> Ahh.
> 
> I guess the proof is in the pudding. Did somebody try to forward-port
> that patch set and see what the performance is like?

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.

There were no problems in forward-porting the patch set to master.
You can find the result here, including a patch makes the TLB flushing
configurable:
http://git.infradead.org/users/jsteckli/linux-xpfo.git/shortlog/refs/heads/xpfo-master

It survived some casual stress-ng runs. I can rerun the benchmarks on
this version, but I doubt there is any change.

> It used to be just 500 LOC. Was that because they took horrible
> shortcuts?

The patch is still fairly small. As for the horrible shortcuts, I let
others comment on that.

HTH,
Julian

[1] Measured on my quad-core (8 hyperthreads) Kaby Lake desktop building
Linux 4.18 with the Phoronix Test Suite.

--
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B