From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752707AbdLKTc6 (ORCPT ); Mon, 11 Dec 2017 14:32:58 -0500 Received: from mga06.intel.com ([134.134.136.31]:7455 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752234AbdLKTc4 (ORCPT ); Mon, 11 Dec 2017 14:32:56 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,392,1508828400"; d="scan'208";a="11459441" Subject: Re: [PATCH PTI v2 6/6] x86/pti: Put the LDT in its own PGD if PTI is on To: Andy Lutomirski References: <90c99eb32b56ea1767472d8b48a524545a551dc6.1512974667.git.luto@kernel.org> <75ec7277-9106-8d61-a75e-bdd1bd640f0b@intel.com> Cc: X86 ML , "linux-kernel@vger.kernel.org" , Borislav Petkov , Brian Gerst , David Laight , Kees Cook , Peter Zijlstra , "Kirill A. Shutemov" From: Dave Hansen Message-ID: <57f0c2d6-4006-f882-e444-e39903f573ec@intel.com> Date: Mon, 11 Dec 2017 11:32:53 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/11/2017 10:40 AM, Andy Lutomirski wrote: >> Also, from a high level, this does increase the overhead of KPTI in a >> non-trivial way, right? It costs us three more page table pages per >> process allocated at fork() and freed at exit() and a new TLB flush. > Yeah, but no one will care. modify_ldt() is used for DOSEMU, Wine, > and really old 32-bit programs. The heavyweight part of map_ldt_struct() (and unmap) looks to run whenever we have KPTI enabled. I'm missing how it gets avoided for the non-DOSEMU cases. I thought there would be a "fast path" where we just use the normal clear_LDT() LDT from the cpu_entry_area and don't have to do any of this, but I'm missing where that happens. Do we need a check in (un)map_ldt_struct() for !mm->context.ldt? Just to make sure I understand this: We now have two places that LDTs live in virtual space: 1. The "plain" one that we get from clear_LDT() which lives in the cpu_entry_area. (No additional overhead when doing this) 2. The new one under the special PGD that's only used for modify_ldt() and is fairly slow. (plenty of overhead, but nobody cares).