From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E12FAECDE46 for ; Thu, 25 Oct 2018 02:18:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8E99D20831 for ; Thu, 25 Oct 2018 02:18:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8E99D20831 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727236AbeJYKtD (ORCPT ); Thu, 25 Oct 2018 06:49:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58484 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726317AbeJYKtD (ORCPT ); Thu, 25 Oct 2018 06:49:03 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D7BE7227CE; Thu, 25 Oct 2018 02:18:25 +0000 (UTC) Received: from localhost (ovpn-8-17.pek2.redhat.com [10.72.8.17]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B031876542; Thu, 25 Oct 2018 02:18:19 +0000 (UTC) Date: Thu, 25 Oct 2018 10:18:09 +0800 From: Baoquan He To: "Kirill A. Shutemov" Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, dave.hansen@linux.intel.com, luto@kernel.org, peterz@infradead.org, boris.ostrovsky@oracle.com, jgross@suse.com, willy@infradead.org, x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCHv2 1/2] x86/mm: Move LDT remap out of KASLR region on 5-level paging Message-ID: <20181025021809.GB2120@MiWiFi-R3L-srv> References: <20181024125112.55999-1-kirill.shutemov@linux.intel.com> <20181024125112.55999-2-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181024125112.55999-2-kirill.shutemov@linux.intel.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 25 Oct 2018 02:18:26 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Kirill, Thanks for making this patchset. I have small concerns, please see the inline comments. On 10/24/18 at 03:51pm, Kirill A. Shutemov wrote: > On 5-level paging LDT remap area is placed in the middle of > KASLR randomization region and it can overlap with direct mapping, > vmalloc or vmap area. > > Let's move LDT just before direct mapping which makes it safe for KASLR. > This also allows us to unify layout between 4- and 5-level paging. In crash utility and makedumpfile which are used to analyze system memory content, PAGE_OFFSET is hardcoded as below in non-KASLR case: #define PAGE_OFFSET_2_6_27 0xffff880000000000 Seems this time they need add another value for them. For 4-level and 5-level, since 5-level code also exist in stable kernel. Surely this doesn't matter much. > > We don't touch 4 pgd slot gap just before the direct mapping reserved > for a hypervisor, but move direct mapping by one slot instead. > > The LDT mapping is per-mm, so we cannot move it into P4D page table next > to CPU_ENTRY_AREA without complicating PGD table allocation for 5-level > paging. Here as discussed in private thread, at the first place you also agreed to put it in p4d entry next to CPU_ENTRY_AREA, but finally you changd mind, there must be some reasons when you implemented and investigated further to find out. Could you please say more about how it will complicating PGD table allocation for 5-level paging? Or give an use case where it will complicate? Very sorry I am stupid, still don't get what's the point. Really appreciate it. Thanks Baoquan