From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (193.142.43.55:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 26 Nov 2019 18:28:57 -0000 Received: from mga06.intel.com ([134.134.136.31]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iZfa3-0002Nx-JG for speck@linutronix.de; Tue, 26 Nov 2019 19:28:56 +0100 Date: Tue, 26 Nov 2019 10:28:52 -0800 From: Andi Kleen Subject: [MODERATED] Re: LVI Message-ID: <20191126182852.GI84886@tassilo.jf.intel.com> References: <20191119174008.7dbymix2eo4mrv57@treble> <20191126005417.GG84886@tassilo.jf.intel.com> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: > Don't you need only half of a Spectrev1 gadget (see the Xen advisory at > https://xenbits.xen.org/xsa/advisory-289.html and the KVM patch at > https://marc.info/?l=kvm&m=157444806904659&w=2)? You need the universal read gadget at least, which is the primary thing a Spectre v1 audit is looking for. My understanding is for the kernel cases it was all the same locations. > Also I assume you didn't take into account using vmexits as an assist. Yes that was missing from the write up, thanks. For vmexit assists there are two cases: - The CPU is not MDS_NO (e.g. pre CLX) and is vulnerable to L1TF: In this case the L1TF mitigations (L1 cache clear and/or core scheduling) are sufficient to avoid an attacker in a guest ever seeing any side effects - The CPU is MDS_NO (e.g. CLX): LVI can only inject 0 values, which are not considered a security risk for normal operation. So no extra changes needed for vmexits. -Andi