From: Baoquan He <bhe@redhat.com>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
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
Date: Thu, 25 Oct 2018 10:18:09 +0800 [thread overview]
Message-ID: <20181025021809.GB2120@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20181024125112.55999-2-kirill.shutemov@linux.intel.com>
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
next prev parent reply other threads:[~2018-10-25 2:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-24 12:51 [PATCHv2 0/2] Fix couple of issues with LDT remap for PTI Kirill A. Shutemov
2018-10-24 12:51 ` [PATCHv2 1/2] x86/mm: Move LDT remap out of KASLR region on 5-level paging Kirill A. Shutemov
2018-10-24 13:12 ` Matthew Wilcox
2018-10-25 2:18 ` Baoquan He [this message]
2018-10-25 7:24 ` Kirill A. Shutemov
2018-10-25 8:11 ` Baoquan He
2018-10-24 12:51 ` [PATCHv2 2/2] x86/ldt: Unmap PTEs for the slot before freeing LDT pages Kirill A. Shutemov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181025021809.GB2120@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).