Received: by 2002:a4a:311b:0:0:0:0:0 with SMTP id k27-v6csp4794274ooa; Tue, 14 Aug 2018 10:38:21 -0700 (PDT) X-Google-Smtp-Source: AA+uWPxLEhhACGALbwiiLdgr2LFzGkCPpDsjNUnNo7VTVXkpqEzjP1n2h3SNzlcNBUoDYAqi8iwl X-Received: by 2002:a63:ab4c:: with SMTP id k12-v6mr21823903pgp.386.1534268301541; Tue, 14 Aug 2018 10:38:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534268301; cv=none; d=google.com; s=arc-20160816; b=MpNVyqXew3hjc7hKbxpe2acHjp+sRiYJObicZf/PBwTeJUMMkObc/uozBE/CSahXTX mvowegOH6P1KNdho/Q+ywLikz9RJZfi3T/CpjRpAEx7ZkSRR5I335Cx0OMWrnVYOHj5q ntFOAv6jjRbGlegTRPWxm2T8NtrS2rDd1StkM8nYjy14mnspCf1dDEBToYdxM5WmBPaT cBYxUmk2b2/CC/EOQMRI6378cGwUFKyzc4SUOT45IWXIzsXSMivld8t27rigWxGOq+Ow wfUaDVDysZvV8XY34u1f0P8vlPrBx38BzoexZVK7+UROn951Yknfy/yY/nm5T/OJwynZ q4cA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=Mck67nYbr8jEiumrT97P2tloBYST6LBEE9elMG0H69U=; b=LVlmKu9PedY1entUlQp3gySHJF6GKpI0YJqjt6b8za2m+jzYk+bzyHN1jku06BBqJW afnGYrU6MIbwiufoR0k+WM2pUQ6CvmvEf70BnoSf/KzyszWeqLsNxYaqlKAu+fMkniS1 L66k/pgaPIKearOoW24+djS26g/7OEBwOTx4xhJIW/nWQUllDBLu8IiII+nJzdvxGJRp 4s0iKIszx3E0j+H2pQtgFeBIfU7+Fmm3csEpKKbj3FSTtncp7tyb5H5VFABfyw2dNTp4 L6Xcd5tDitsOv4o9uYhMioQ8vVK3owK5ZmrJ2+fhtsNHgf1Jwbdwz1wVMlCSagB4QPlE Otlg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l15-v6si21371730pgh.593.2018.08.14.10.38.06; Tue, 14 Aug 2018 10:38:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730200AbeHNUYG (ORCPT + 99 others); Tue, 14 Aug 2018 16:24:06 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:57364 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729803AbeHNUYG (ORCPT ); Tue, 14 Aug 2018 16:24:06 -0400 Received: from localhost (unknown [194.244.16.108]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id CCF63DDE; Tue, 14 Aug 2018 17:35:56 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Vlastimil Babka , Thomas Gleixner , Michal Hocko Subject: [PATCH 4.14 052/104] x86/speculation/l1tf: Protect PAE swap entries against L1TF Date: Tue, 14 Aug 2018 19:17:06 +0200 Message-Id: <20180814171518.710914649@linuxfoundation.org> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20180814171515.270692185@linuxfoundation.org> References: <20180814171515.270692185@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Vlastimil Babka commit 0d0f6249058834ffe1ceaad0bb31464af66f6e7a upstream 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. Signed-off-by: Vlastimil Babka Signed-off-by: Thomas Gleixner Acked-by: Michal Hocko Signed-off-by: Greg Kroah-Hartman --- arch/x86/include/asm/pgtable-3level.h | 35 ++++++++++++++++++++++++++++++++-- arch/x86/mm/init.c | 2 - 2 files changed, 34 insertions(+), 3 deletions(-) --- a/arch/x86/include/asm/pgtable-3level.h +++ b/arch/x86/include/asm/pgtable-3level.h @@ -206,12 +206,43 @@ static inline pud_t native_pudp_get_and_ #endif /* Encode and de-code a swap entry */ +#define SWP_TYPE_BITS 5 + +#define SWP_OFFSET_FIRST_BIT (_PAGE_BIT_PROTNONE + 1) + +/* We always extract/encode the offset by shifting it all the way up, and then down again */ +#define SWP_OFFSET_SHIFT (SWP_OFFSET_FIRST_BIT + SWP_TYPE_BITS) + #define MAX_SWAPFILES_CHECK() BUILD_BUG_ON(MAX_SWAPFILES_SHIFT > 5) #define __swp_type(x) (((x).val) & 0x1f) #define __swp_offset(x) ((x).val >> 5) #define __swp_entry(type, offset) ((swp_entry_t){(type) | (offset) << 5}) -#define __pte_to_swp_entry(pte) ((swp_entry_t){ (pte).pte_high }) -#define __swp_entry_to_pte(x) ((pte_t){ { .pte_high = (x).val } }) + +/* + * Normally, __swp_entry() converts from arch-independent swp_entry_t to + * arch-dependent swp_entry_t, and __swp_entry_to_pte() just stores the result + * to pte. But here we have 32bit swp_entry_t and 64bit pte, and need to use the + * whole 64 bits. Thus, we shift the "real" arch-dependent conversion to + * __swp_entry_to_pte() through the following helper macro based on 64bit + * __swp_entry(). + */ +#define __swp_pteval_entry(type, offset) ((pteval_t) { \ + (~(pteval_t)(offset) << SWP_OFFSET_SHIFT >> SWP_TYPE_BITS) \ + | ((pteval_t)(type) << (64 - SWP_TYPE_BITS)) }) + +#define __swp_entry_to_pte(x) ((pte_t){ .pte = \ + __swp_pteval_entry(__swp_type(x), __swp_offset(x)) }) +/* + * Analogically, __pte_to_swp_entry() doesn't just extract the arch-dependent + * swp_entry_t, but also has to convert it from 64bit to the 32bit + * intermediate representation, using the following macros based on 64bit + * __swp_type() and __swp_offset(). + */ +#define __pteval_swp_type(x) ((unsigned long)((x).pte >> (64 - SWP_TYPE_BITS))) +#define __pteval_swp_offset(x) ((unsigned long)(~((x).pte) << SWP_TYPE_BITS >> SWP_OFFSET_SHIFT)) + +#define __pte_to_swp_entry(pte) (__swp_entry(__pteval_swp_type(pte), \ + __pteval_swp_offset(pte))) #define gup_get_pte gup_get_pte /* --- a/arch/x86/mm/init.c +++ b/arch/x86/mm/init.c @@ -896,7 +896,7 @@ unsigned long max_swapfile_size(void) * We encode swap offsets also with 3 bits below those for pfn * which makes the usable limit higher. */ -#ifdef CONFIG_X86_64 +#if CONFIG_PGTABLE_LEVELS > 2 l1tf_limit <<= PAGE_SHIFT - SWP_OFFSET_FIRST_BIT; #endif pages = min_t(unsigned long, l1tf_limit, pages);