From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752918AbdLKNjv (ORCPT ); Mon, 11 Dec 2017 08:39:51 -0500 Received: from mail-wr0-f195.google.com ([209.85.128.195]:33949 "EHLO mail-wr0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751688AbdLKNjt (ORCPT ); Mon, 11 Dec 2017 08:39:49 -0500 X-Google-Smtp-Source: ACJfBovz6ImxvvDKu6Mh68KbcOQjc7N+qi2SQ+Nc+VEZKnEDyMAf8rPchr5TMBV9VfsZtlUnpIYaZg== Date: Mon, 11 Dec 2017 14:39:45 +0100 From: Ingo Molnar To: Andy Lutomirski Cc: x86@kernel.org, linux-kernel@vger.kernel.org, Borislav Petkov , Brian Gerst , David Laight , Kees Cook , Peter Zijlstra Subject: Re: [PATCH PTI v2 3/6] x86/vsyscall/64: Explicitly set _PAGE_USER in the pagetable hierarchy Message-ID: <20171211133945.pmsgwfj2b5py44gj@gmail.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Andy Lutomirski wrote: > The kernel is very erratic as to which pagetables have _PAGE_USER > set. The vsyscall page gets lucky: it seems that all of the > relevant pagetables are among the apparently arbitrary ones that set > _PAGE_USER. Rather than relying on chance, just explicitly set > _PAGE_USER. > > This will let us clean up pagetable setup to stop setting > _PAGE_USER. The added code can also be reused by pagetable > isolation to manage the _PAGE_USER bit in the usermode tables. > > Signed-off-by: Andy Lutomirski > --- > arch/x86/entry/vsyscall/vsyscall_64.c | 33 ++++++++++++++++++++++++++++++++- > 1 file changed, 32 insertions(+), 1 deletion(-) Btw., would it make sense to clean up all this confusion? In particular a 'KERNEL' pre of post fix is ambiguous in this context I think, and the PAGE_KERNEL_ prefix is actively harmful I think and is at the root of the confusion. So if renamed it and used this nomenclature consistently instead: PAGE_USER_ PAGE_SYSTEM_ ... and got rid of PAGE_KERNEL uses in arch/x86/, then it would be obvious at first glance what kind of mapping is established in a particular place - and it would stay so in the future as well. ( There's some interaction with generic MM code which needs the original defines like PAGE_KERNEL[_EXEC], but those generic masks could be defined as aliases, to keep this cleanup within x86 for now. ) Thanks, Ingo