Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp154479imm; Thu, 2 Aug 2018 15:59:35 -0700 (PDT) X-Google-Smtp-Source: AAOMgpflFofxZ6lhOsJtZG6/J63iGO60ouQo3wksI9wyVNn2ckflZ5F+rTOzXDiVhgiWpen/13eg X-Received: by 2002:a62:49cf:: with SMTP id r76-v6mr1422969pfi.235.1533250775375; Thu, 02 Aug 2018 15:59:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533250775; cv=none; d=google.com; s=arc-20160816; b=weX4QnA7pD+PFBCUpPvc1RJndtJ3p4Nwl8P7sHdv3TfTfgNOGlwPT8UfYPXeH01A4N ctQKIYsreNT2D8i/uXMM+ZAzvv0DjM5GGrg+ARYbPlGtvTRAHw3a4XSSD9UBWtqlJTnc bx8XOF02eE06kafu8zfU1NOXLZARxgqLad2bXKFovrAGg0zuph3S9WYwoSirWSbh1sd5 /PqEgnSPfxLITETxGld9WYcBHjdNcton3yKTIs96s2OwMrqxU8CuVCOT3vkgJS9sb+nw ZiX+YPTYF51LFgpl1o3r7HdLl+mKqOCB0TGXA12d9rT1jOvA37i+wIz9EMP/ZSq0/dqu IPKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:from:cc:to:subject :arc-authentication-results; bh=AtgQsbH5wuY/nS5IwSN56gs6F/kdJQnnYMS6ACRXoms=; b=fo+5OXuJ0hgYZmJWc6fyW42phQYqI9neOcpMDQupHHvmDs9bkgFkVRvPV/oL1ALERg OqqHIsAiQ3HZ/Dq2H1aMkVWxSQBVTGMazVwXZKF+34wH65M8qeQSocoJQZLRQyWbSJ2b pjXMYB5fdOYcC+QTbsEFi90SB5G8XgpKZwzYMO0Z0ajfBVOsYGDy7WAmSvX1MiRM7bK+ K9dauOImK6DiCnC3E3Yaz0UCMMjvepZ4w0PX3HOEKwRajMUmDpW+DvTP6BCvWMi7Otyv L3D/IpacweA5Id38mBBsv/jQLsPnyIwHoYTkggj8ptOzouGeNuOjpH+vMk5kc4g+yFUM GgyA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 87-v6si3260341pfi.60.2018.08.02.15.59.20; Thu, 02 Aug 2018 15:59:35 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731500AbeHCAvu (ORCPT + 99 others); Thu, 2 Aug 2018 20:51:50 -0400 Received: from mga04.intel.com ([192.55.52.120]:44440 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727262AbeHCAvu (ORCPT ); Thu, 2 Aug 2018 20:51:50 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Aug 2018 15:58:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,437,1526367600"; d="scan'208";a="62903921" Received: from viggo.jf.intel.com (HELO localhost.localdomain) ([10.54.77.144]) by orsmga006.jf.intel.com with ESMTP; 02 Aug 2018 15:58:32 -0700 Subject: [PATCH 0/7] [v2] x86/mm/pti: close two Meltdown leaks with Global kernel mapping To: linux-kernel@vger.kernel.org Cc: Dave Hansen , keescook@google.com, tglx@linutronix.de, mingo@kernel.org, aarcange@redhat.com, jgross@suse.com, jpoimboe@redhat.com, gregkh@linuxfoundation.org, peterz@infradead.org, hughd@google.com, torvalds@linux-foundation.org, bp@alien8.de, luto@kernel.org, ak@linux.intel.com From: Dave Hansen Date: Thu, 02 Aug 2018 15:58:23 -0700 Message-Id: <20180802225823.4711C55B@viggo.jf.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The fixes for the problem Hugh reported took a bit more surgery than I would have liked, but they do appear to work. Note that the last two patches are unnecessary cleanups that could be removed from backports. Changes from v1: * Modify set_memory_np() to avoid messing with the direct map by limiting its changes to the high kernel image map. -- This applies to 4.17 and 4.18. Thanks to Hugh Dickins for initially finding the r/w kernel text issue and coming up with an initial fix. I found the "unused hole" part and came up with different approach for fixing the mess. -- Background: Process Context IDentifiers (PCIDs) are a hardware feature that allows TLB entries to survive page table switches (CR3 writes). As an optimization, the PTI code currently allows the kernel image to be Global when running on hardware without PCIDs. This results in fewer TLB misses, especially upon entry. The downside is that these Global areas are theoretically susceptible to Meltdown. The logic is that there are no secrets in the kernel image, so why pay the cost of TLB misses. Problem: The current PTI code leaves the entire area of the kernel binary between '_text' and '_end' as Global (on non-PCID hardware). However, that range contains both read-write kernel data, and two "unused" holes in addition to text. The areas which are not text or read-only might contain secrets once they are freed back into the allocator. This issue affects systems which are susceptible to Meltdown, do not have PCIDs and which are using the default PTI_AUTO mode (no pti=on/off on the cmdline). PCIDs became generally available for servers in ~2010 (Westmere) and desktop (client) parts in roughly 2011 (Sandybridge). This is not expected to affect anything newer than that. Solution: The solution for the read-write area is to clear the global bit for the area (patch #1). The "unused" holes need a bit more work since we free them in a bit of an ad-hoc way, but we fix this up in patches 2-5. Cc: Kees Cook Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Andrea Arcangeli Cc: Juergen Gross Cc: Josh Poimboeuf Cc: Greg Kroah-Hartman Cc: Peter Zijlstra Cc: Hugh Dickins Cc: Linus Torvalds Cc: Borislav Petkov Cc: Andy Lutomirski Cc: Andi Kleen