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 ; 12 Jun 2018 16:13:51 -0000 Received: from hsi-kbw-5-158-153-52.hsi19.kabel-badenwuerttemberg.de ([5.158.153.52] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fSlva-0000oq-Mc for speck@linutronix.de; Tue, 12 Jun 2018 18:13:50 +0200 Date: Tue, 12 Jun 2018 18:13:50 +0200 (CEST) From: Thomas Gleixner Subject: Re: [PATCH 2/8] L1TFv7 4 In-Reply-To: <20180607232452.BB0E3610FC@crypto-ml.lab.linutronix.de> Message-ID: References: <20180607232452.BB0E3610FC@crypto-ml.lab.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Thu, 7 Jun 2018, speck for ak_at_linux.intel.com wrote: > From: Linus Torvalds > Subject: x86/speculation/l1tf: Protect swap entries against L1TF > > With L1 terminal fault the CPU speculates into unmapped PTEs, and > resulting side effects allow to read the memory the PTE is pointing > too, if its values are still in the L1 cache. > > For swapped out pages Linux uses unmapped PTEs and stores a swap entry > into them. > > We need to make sure the swap entry is not pointing to valid memory, > which requires setting higher bits (between bit 36 and bit 45) that > are inside the CPUs physical address space, but outside any real > memory. > > To do this we invert the offset to make sure the higher bits are always > set, as long as the swap file is not too big. > > Here's a patch that switches the order of "type" and > "offset" in the x86-64 encoding, in addition to doing the binary 'not' on > the offset. > > That means that now the offset is bits 9-58 in the page table, and that > the type is in the bits that hardware generally doesn't care about. > > That, in turn, means that if you have a desktop chip with only 40 bits of > physical addressing, now that the offset starts at bit 9, you still have > to have 30 bits of offset actually *in use* until bit 39 ends up being > clear. > > So that's 4 terabyte of swap space (because the offset is counted in > pages, so 30 bits of offset is 42 bits of actual coverage). With bigger > physical addressing, that obviously grows further, until you hit the limit > of the offset (at 50 bits of offset - 62 bits of actual swap file > coverage). > > Note there is no workaround for 32bit !PAE, or on systems which > have more than MAX_PA/2 memory. The later case is very unlikely > to happen on real systems. There is also Peters earlier request outstanding: Message-ID: 20180502080432.GA12180@hirez.programming.kicks-ass.net I would've expected patch 1 to be two separate patches; one flipping the fields the other flipping the bits. That's just a wee bit easier to look at. Thanks, tglx