From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752239AbeAFGcY (ORCPT + 1 other); Sat, 6 Jan 2018 01:32:24 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:3695 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751422AbeAFGcW (ORCPT ); Sat, 6 Jan 2018 01:32:22 -0500 Subject: Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch) To: Dave Hansen , Jiri Kosina CC: Yisheng Xie , , , , , , , , Linus Torvalds , , , , Andrea Arcangeli References: <20171123003438.48A0EEDE@viggo.jf.intel.com> <20171123003447.1DB395E3@viggo.jf.intel.com> <93776eb2-b6d4-679a-280c-8ba558a69c34@linux.intel.com> <20a54a5f-f4e5-2126-fb73-6a995d13d52d@linux.intel.com> <332f4eab-8a3d-8b29-04f2-7c075f81b85b@linux.intel.com> From: Hanjun Guo Message-ID: Date: Sat, 6 Jan 2018 14:28:52 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <332f4eab-8a3d-8b29-04f2-7c075f81b85b@linux.intel.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.223.23] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: Hi Dave, Thank you very much for the quick response! Minor comments inline. On 2018/1/6 14:06, Dave Hansen wrote: > On 01/05/2018 08:54 PM, Hanjun Guo wrote: >> Do you mean NX bit will be brought back later? I'm asking this because >> I tested this patch which it fixed the boot panic issue but the system >> will hang when rebooting the system, because rebooting will also call efi >> then panic as NS bit is set. > Wow, you're running a lot of very lighly-used code paths! You actually > found a similar but totally separate issue from what I gather. Thank > you immensely for the quick testing and bug reports! > > Could you test the attached fix? > > For those playing along at home, I think this will end up being needed > for 4.15 and probably all the backports. I want to see if it works > before I submit it for real, though. > > > pti-tboot-fix.patch > > > From: Dave Hansen > > This is another case similar to what EFI does: create a new set of > page tables, map some code at a low address, and jump to it. PTI > mistakes this low address for userspace and mistakenly marks it > non-executable in an effort to make it unusable for userspace. Undo > the poison to allow execution. > > Signed-off-by: Dave Hansen > Cc: Ning Sun > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > Cc: x86@kernel.org > Cc: tboot-devel@lists.sourceforge.net > Cc: linux-kernel@vger.kernel.org > --- > > b/arch/x86/kernel/tboot.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff -puN arch/x86/kernel/tboot.c~pti-tboot-fix arch/x86/kernel/tboot.c > --- a/arch/x86/kernel/tboot.c~pti-tboot-fix 2018-01-05 21:50:55.755554960 -0800 > +++ b/arch/x86/kernel/tboot.c 2018-01-05 22:01:51.393553325 -0800 > @@ -124,6 +124,13 @@ static int map_tboot_page(unsigned long > pte_t *pte; > > pgd = pgd_offset(&tboot_mm, vaddr); > + /* > + * PTI poisons low addresses in the kernel page tables in the > + * name of making them unusable for userspace. To execute > + * code at such a low address, the poison must be cleared. > + */ > + pgd->pgd &= ~_PAGE_NX; ... > + > p4d = p4d_alloc(&tboot_mm, pgd, vaddr); Seems pgd will be re-set after p4d_alloc(), so should we put the code behind (or after pud_alloc())? > if (!p4d) > return -1; + /* + * PTI poisons low addresses in the kernel page tables in the + * name of making them unusable for userspace. To execute + * code at such a low address, the poison must be cleared. + */ + pgd->pgd &= ~_PAGE_NX; We will have a try in a minute, and report back later. Thanks Hanjun