From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx3-rdu2.redhat.com ([66.187.233.73] helo=mx1.redhat.com) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fAzaY-0005Eo-11 for speck@linutronix.de; Tue, 24 Apr 2018 17:10:38 +0200 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 939CA42709C9 for ; Tue, 24 Apr 2018 15:10:31 +0000 (UTC) Received: from washington.bos.jonmasters.org (ovpn-126-71.rdu2.redhat.com [10.10.126.71]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5F646215CDCB for ; Tue, 24 Apr 2018 15:10:31 +0000 (UTC) Subject: [MODERATED] Re: L1D-Fault KVM mitigation References: <20180424090630.wlghmrpasn7v7wbn@suse.de> <20180424093537.GC4064@hirez.programming.kicks-ass.net> <1524563292.8691.38.camel@infradead.org> <20180424110445.GU4043@hirez.programming.kicks-ass.net> <1524568571.8691.45.camel@infradead.org> From: Jon Masters Message-ID: <9649d701-6bc2-b127-2b22-924804ff569a@redhat.com> Date: Tue, 24 Apr 2018 11:10:30 -0400 MIME-Version: 1.0 In-Reply-To: <1524568571.8691.45.camel@infradead.org> Content-Type: multipart/mixed; boundary="aLWmbaa2i4IhTRYOo3EzgurAp43v07n61"; protected-headers="v1" To: speck@linutronix.de List-ID: This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156) --aLWmbaa2i4IhTRYOo3EzgurAp43v07n61 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/24/2018 07:16 AM, speck for David Woodhouse wrote: > On Tue, 2018-04-24 at 13:04 +0200, speck for Peter Zijlstra wrote: >> Not sure I'm following. The above assumes a sibling is running a >> VCPU of another VM, right? But it could equally well run any regular >> old task (including idle). >> So only pausing siblings in VMX mode wouldn't help anything. The >> !VMX tasks could still be loading stuff into L1. > Er, yeah... I may have briefly forgotten that some people sometimes > run actual userspace, not just VM guests. :) More than once over the past few months, I've pointed out that Annapurna was the right way to go. Personally, I think the only possible way to make any of this safe is by moving "all" userspace off host like AMZ. > It's ring 3 *and* VMX non-root which would need to be paused on HT > siblings. And it would need to be triggered on any transition back > into the kernel from userspace too, not just vmexit. Which makes it a > little bit harder. The additional ucode hack (pausing the sibling thread) has been discussed at some length already. It's a good idea, except for the host side as you note, and there we have all manner of interrupts to handle. In the case of a traditional OS on the host, that's a lot of code happily pulling secrets into the L1 and lots of paths to track if we wanted to do like one of the others (dunno if I can say who, but someone is tracking all secrets loaded into the L1 and scrubbing them after, but they also refactored enough other stuff to make that just about work). On our end, we've discussed automatic handling at boot along the lines that have been pondered this morning here. The problem is that you don't want to penalize until people run KVM, and you don't want to them hot unplug or do crazy things that might affect tunings (I already got shot down, rightly, for suggesting that one). So, instead, it's going to have to be messaging, and maybe tainting as insecure of some kind. I've requested that RHEL's installer be modified to effectively add a checkbox that defaults to enabled but very prominently offers to disable HT if you're using virtualization. We'll then need some guidance coordinated across the industry that for total security (even in the face of some of the gang scheduling proposals) you need to !HT. Jon. --=20 Computer Architect | Sent from my Fedora powered laptop --aLWmbaa2i4IhTRYOo3EzgurAp43v07n61--