From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (146.0.238.70:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 05 Mar 2019 15:34:50 -0000 Received: from p5492e5b8.dip0.t-ipconnect.de ([84.146.229.184] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1h1C5h-0001Us-1I for speck@linutronix.de; Tue, 05 Mar 2019 16:34:49 +0100 Date: Tue, 5 Mar 2019 16:34:48 +0100 (CET) From: Thomas Gleixner Subject: Re: Encrypted Message In-Reply-To: Message-ID: References: <20190301214738.281554861@linutronix.de> <20190301214847.896222054@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Mon, 4 Mar 2019, speck for Jon Masters wrote: > On 3/1/19 4:47 PM, speck for Thomas Gleixner wrote: > > if (static_branch_unlikely(&vmx_l1d_should_flush)) > > vmx_l1d_flush(vcpu); > > + else if (static_branch_unlikely(&mds_user_clear)) > > + mds_clear_cpu_buffers(); > > Does this cover the case where we have older ucode installed that does > L1D flush but NOT the MD_CLEAR? I'm about to go check to see if there's > logic handling this but wanted to call it out. If no updated microcode is available then it's pretty irrelevant which code path you take. None of them will mitigate MDS. Thanks, tglx