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 ; 26 Jun 2018 13:05:10 -0000 Received: from mx2.suse.de ([195.135.220.15]) by Galois.linutronix.de with esmtps (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1fXnef-0000yv-27 for speck@linutronix.de; Tue, 26 Jun 2018 15:05:09 +0200 Received: from relay2.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id CB6CFAC73 for ; Tue, 26 Jun 2018 13:05:03 +0000 (UTC) Date: Tue, 26 Jun 2018 15:05:03 +0200 From: Michal Hocko Subject: [MODERATED] Re: [PATCH 8/8] L1TFv8 6 Message-ID: <20180626130503.GX28965@dhcp22.suse.cz> References: <20180614150632.E064C61183@crypto-ml.lab.linutronix.de> <4ad5c4d2-7721-729e-3af6-6c8ed84dda9f@suse.cz> <260fce1e-c5fe-cace-56a8-a83c2a41f115@suse.cz> <20180622165652.GX30690@tassilo.jf.intel.com> <20180625203154.GB19456@tassilo.jf.intel.com> <59926fa8-c26b-b5e0-6817-55d6921ed2fd@suse.cz> <20180626125750.GW28965@dhcp22.suse.cz> MIME-Version: 1.0 In-Reply-To: <20180626125750.GW28965@dhcp22.suse.cz> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Tue 26-06-18 14:57:50, speck for Michal Hocko wrote: > On Tue 26-06-18 14:01:18, speck for Vlastimil Babka wrote: > > On 06/25/2018 10:31 PM, speck for Andi Kleen wrote: > [...] > > >From 94b19f2277984594eda826a315cb49d6be5375b5 Mon Sep 17 00:00:00 2001 > > From: Vlastimil Babka > > Date: Fri, 22 Jun 2018 17:39:33 +0200 > > Subject: [PATCH] x86/speculation/l1tf: protect PAE swap entries against L1TF > > > > The PAE 3-level paging code currently doesn't mitigate L1TF by flipping the > > offset bits, and uses the high PTE word, thus bits 32-36 for type, 37-63 for > > offset. The lower word is zeroed, thus systems with less than 4GB memory are > > safe. With 4GB to 128GB the swap type selects the memory locations vulnerable > > to L1TF; with even more memory, also the swap offfset influences the address. > > This might be a problem with 32bit PAE guests running on large 64bit hosts. > > > > By continuing to keep the whole swap entry in either high or low 32bit word of > > PTE we would limit the swap size too much. Thus this patch uses the whole PAE > > PTE with the same layout as the 64bit version does. The macros just become a > > bit tricky since they assume the arch-dependent swp_entry_t to be 32bit. > > I have expected this to be even ugglier but it seems quite sane in the > end. And just for the record. I was worried that the 64b swap entry would lead to RMW issues because we are not doing the single write to u64 on 32b but all swap entries constructors I can see are local and only made visible later. Regular ptes handle that already but I was worried that having swap entries special could lead to some subtle issues but I cannot see any in the code. > > Signed-off-by: Vlastimil Babka > > Acked-by: Michal Hocko > > Thanks! -- Michal Hocko SUSE Labs