[Linux-stable-mirror] [PATCH 4.4] vsyscall: Fix permissions for emulate mode with KAISER/PTI
The backport of KAISER to 4.4 turned vsyscall emulate mode into native mode. Add a vsyscall_pgprot variable to hold the correct page protections, like Borislav and Hugh did for 3.2 and 3.18.
Cc: Borislav Petkov bp@suse.de Cc: Hugh Dickins hughd@google.com Signed-off-by: Ben Hutchings ben.hutchings@codethink.co.uk --- I think this is also needed for 4.9 but haven't tested there.
Ben.
arch/x86/entry/vsyscall/vsyscall_64.c | 7 ++++--- arch/x86/include/asm/vsyscall.h | 1 + arch/x86/mm/kaiser.c | 2 +- 3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscall/vsyscall_64.c index 112178b401a1..2d359991a273 100644 --- a/arch/x86/entry/vsyscall/vsyscall_64.c +++ b/arch/x86/entry/vsyscall/vsyscall_64.c @@ -46,6 +46,7 @@ static enum { EMULATE, NATIVE, NONE } vsyscall_mode = #else EMULATE; #endif +unsigned long vsyscall_pgprot = __PAGE_KERNEL_VSYSCALL;
static int __init vsyscall_setup(char *str) { @@ -336,11 +337,11 @@ void __init map_vsyscall(void) extern char __vsyscall_page; unsigned long physaddr_vsyscall = __pa_symbol(&__vsyscall_page);
+ if (vsyscall_mode != NATIVE) + vsyscall_pgprot = __PAGE_KERNEL_VVAR; if (vsyscall_mode != NONE) __set_fixmap(VSYSCALL_PAGE, physaddr_vsyscall, - vsyscall_mode == NATIVE - ? PAGE_KERNEL_VSYSCALL - : PAGE_KERNEL_VVAR); + __pgprot(vsyscall_pgprot));
BUILD_BUG_ON((unsigned long)__fix_to_virt(VSYSCALL_PAGE) != (unsigned long)VSYSCALL_ADDR); diff --git a/arch/x86/include/asm/vsyscall.h b/arch/x86/include/asm/vsyscall.h index 4865e10dbb55..9ee85066f407 100644 --- a/arch/x86/include/asm/vsyscall.h +++ b/arch/x86/include/asm/vsyscall.h @@ -13,6 +13,7 @@ extern void map_vsyscall(void); */ extern bool emulate_vsyscall(struct pt_regs *regs, unsigned long address); extern bool vsyscall_enabled(void); +extern unsigned long vsyscall_pgprot; #else static inline void map_vsyscall(void) {} static inline bool emulate_vsyscall(struct pt_regs *regs, unsigned long address) diff --git a/arch/x86/mm/kaiser.c b/arch/x86/mm/kaiser.c index 8af98513d36c..2298434f7bdb 100644 --- a/arch/x86/mm/kaiser.c +++ b/arch/x86/mm/kaiser.c @@ -345,7 +345,7 @@ void __init kaiser_init(void) if (vsyscall_enabled()) kaiser_add_user_map_early((void *)VSYSCALL_ADDR, PAGE_SIZE, - __PAGE_KERNEL_VSYSCALL); + vsyscall_pgprot);
for_each_possible_cpu(cpu) { void *percpu_vaddr = __per_cpu_user_mapped_start +
On Fri, Jan 26, 2018 at 04:23:02PM +0000, Ben Hutchings wrote:
The backport of KAISER to 4.4 turned vsyscall emulate mode into native mode. Add a vsyscall_pgprot variable to hold the correct page protections, like Borislav and Hugh did for 3.2 and 3.18.
Cc: Borislav Petkov bp@suse.de Cc: Hugh Dickins hughd@google.com Signed-off-by: Ben Hutchings ben.hutchings@codethink.co.uk
I think this is also needed for 4.9 but haven't tested there.
Yeah, looks like 4.9 also needs this. Thanks a lot for this, I didn't think to look at the older backports recently.
greg k-h
On Fri, 26 Jan 2018, Greg Kroah-Hartman wrote:
On Fri, Jan 26, 2018 at 04:23:02PM +0000, Ben Hutchings wrote:
The backport of KAISER to 4.4 turned vsyscall emulate mode into native mode. Add a vsyscall_pgprot variable to hold the correct page protections, like Borislav and Hugh did for 3.2 and 3.18.
Oh yes, you're right, Ben: I was uneasy about the lack of vsyscall_pgprot there, but had completely paged-out how it's the faulting that makes emulate emulate instead of native. Thanks a lot for the fixup.
But I hope "3.18" there is an unimportant typo (perhaps for "3.8"), rather than evidence that I've lost my marbles - I did indeed supply 3.18.72-based tarfiles early on, but those were before we'd even begun to look into unbreaking vsyscalls.
I haven't updated those 3.18 patches since that time, and was a day or two away from asking you, Greg, what is the status of 3.18? I didn't bother to update those patches because I saw it marked EOL as soon as Meltdown+Spectre was announced; yet it now appears to have a life beyond death, getting non-Meltdown+Spectre updates every week or so.
I can certainly (but not until next week) put together a 3.18.92- based tarfile or tarfiles, equivalent to what I sent for 3.8 and 3.10 (on kaiser-discuss backports list) a couple of days ago. That is, like what I sent before for 3.18.72, but with all the fixups and pti= boot option and KAISER->PAGE_TABLE_ISOLATION renaming that's come in since (But I cannot bear to go further myself, into retpoline etc, sorry.)
Would a 3.18 Kaiser update be helpful, or are you preferring to force people off 3.18 by not providing those updates? Or preferring to wait a bit longer, until 4.4 and 4.9 and 4.14 have settled down?
Cc: Borislav Petkov bp@suse.de Cc: Hugh Dickins hughd@google.com Signed-off-by: Ben Hutchings ben.hutchings@codethink.co.uk
I think this is also needed for 4.9 but haven't tested there.
Yeah, looks like 4.9 also needs this. Thanks a lot for this, I didn't think to look at the older backports recently.
Yes, the same for 4.9 is good, thank you.
And no need for you to delve into those older backports, we'll keep you up to date if anything does come up there - though perhaps with a few days delay - I've two or three updates to 4.4 and 4.9 which came to light while researching what 3.8 needed, but still won't have time to assemble patches for you today.
(I'm thinking Dave Hansen's tboot fix needed, and perf fix for Robert Swiecki's intel_bts crash; and Pavel Tatashin's pgd allocation change might be over-allocating when pti=off, I've not tested yet but it looked that way.)
Hugh
On Fri, Jan 26, 2018 at 12:23:17PM -0800, Hugh Dickins wrote:
I haven't updated those 3.18 patches since that time, and was a day or two away from asking you, Greg, what is the status of 3.18? I didn't bother to update those patches because I saw it marked EOL as soon as Meltdown+Spectre was announced; yet it now appears to have a life beyond death, getting non-Meltdown+Spectre updates every week or so.
I am not doing any Meltdown/Spectre patches for 3.18, because yes, it really is EOL. I am only continuing to maintain it because there are some vendors that rely on it at the moment, and they usually just take these releases + the android-common kernel tree together. As the needed ARM Meltdown patches are in the android-common tree right now (and not really anywhere else at all), that is sufficient for their use.
I can certainly (but not until next week) put together a 3.18.92- based tarfile or tarfiles, equivalent to what I sent for 3.8 and 3.10 (on kaiser-discuss backports list) a couple of days ago. That is, like what I sent before for 3.18.72, but with all the fixups and pti= boot option and KAISER->PAGE_TABLE_ISOLATION renaming that's come in since (But I cannot bear to go further myself, into retpoline etc, sorry.)
Would a 3.18 Kaiser update be helpful, or are you preferring to force people off 3.18 by not providing those updates? Or preferring to wait a bit longer, until 4.4 and 4.9 and 4.14 have settled down?
I'm not recommending anyone use the 3.18 tree unless they know what they are doing right now :)
And yes, I would love for them to move off of that tree as soon as possible, but usually due to huge out-of-tree SoC patches, they can not do that easily, if at all, right now.
So no need for a 3.18 Kaiser update for me at all, I do not need or want it.
thanks,
greg k-h
On Sun, Jan 28, 2018 at 4:13 AM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Fri, Jan 26, 2018 at 12:23:17PM -0800, Hugh Dickins wrote:
I haven't updated those 3.18 patches since that time, and was a day or two away from asking you, Greg, what is the status of 3.18? I didn't bother to update those patches because I saw it marked EOL as soon as Meltdown+Spectre was announced; yet it now appears to have a life beyond death, getting non-Meltdown+Spectre updates every week or so.
I am not doing any Meltdown/Spectre patches for 3.18, because yes, it really is EOL. I am only continuing to maintain it because there are some vendors that rely on it at the moment, and they usually just take these releases + the android-common kernel tree together. As the needed ARM Meltdown patches are in the android-common tree right now (and not really anywhere else at all), that is sufficient for their use.
I can certainly (but not until next week) put together a 3.18.92- based tarfile or tarfiles, equivalent to what I sent for 3.8 and 3.10 (on kaiser-discuss backports list) a couple of days ago. That is, like what I sent before for 3.18.72, but with all the fixups and pti= boot option and KAISER->PAGE_TABLE_ISOLATION renaming that's come in since (But I cannot bear to go further myself, into retpoline etc, sorry.)
Would a 3.18 Kaiser update be helpful, or are you preferring to force people off 3.18 by not providing those updates? Or preferring to wait a bit longer, until 4.4 and 4.9 and 4.14 have settled down?
I'm not recommending anyone use the 3.18 tree unless they know what they are doing right now :)
And yes, I would love for them to move off of that tree as soon as possible, but usually due to huge out-of-tree SoC patches, they can not do that easily, if at all, right now.
So no need for a 3.18 Kaiser update for me at all, I do not need or want it.
Okay, that's very clear now - thanks.
Hugh
This is a note to let you know that I've just added the patch titled
vsyscall: Fix permissions for emulate mode with KAISER/PTI
to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git%3Ba=su...
The filename of the patch is: vsyscall-fix-permissions-for-emulate-mode-with-kaiser-pti.patch and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let stable@vger.kernel.org know about it.
From ben.hutchings@codethink.co.uk Fri Jan 26 17:35:59 2018
From: Ben Hutchings ben.hutchings@codethink.co.uk Date: Fri, 26 Jan 2018 16:23:02 +0000 Subject: vsyscall: Fix permissions for emulate mode with KAISER/PTI To: Greg Kroah-Hartman gregkh@linuxfoundation.org Cc: Borislav Petkov bp@suse.de, Hugh Dickins hughd@google.com, stable@vger.kernel.org Message-ID: 20180126162302.ei4tmiltl73npmr6@xylophone.i.decadent.org.uk
From: Ben Hutchings ben.hutchings@codethink.co.uk
The backport of KAISER to 4.4 turned vsyscall emulate mode into native mode. Add a vsyscall_pgprot variable to hold the correct page protections, like Borislav and Hugh did for 3.2 and 3.18.
Cc: Borislav Petkov bp@suse.de Cc: Hugh Dickins hughd@google.com Signed-off-by: Ben Hutchings ben.hutchings@codethink.co.uk Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- arch/x86/entry/vsyscall/vsyscall_64.c | 7 ++++--- arch/x86/include/asm/vsyscall.h | 1 + arch/x86/mm/kaiser.c | 2 +- 3 files changed, 6 insertions(+), 4 deletions(-)
--- a/arch/x86/entry/vsyscall/vsyscall_64.c +++ b/arch/x86/entry/vsyscall/vsyscall_64.c @@ -46,6 +46,7 @@ static enum { EMULATE, NATIVE, NONE } vs #else EMULATE; #endif +unsigned long vsyscall_pgprot = __PAGE_KERNEL_VSYSCALL;
static int __init vsyscall_setup(char *str) { @@ -336,11 +337,11 @@ void __init map_vsyscall(void) extern char __vsyscall_page; unsigned long physaddr_vsyscall = __pa_symbol(&__vsyscall_page);
+ if (vsyscall_mode != NATIVE) + vsyscall_pgprot = __PAGE_KERNEL_VVAR; if (vsyscall_mode != NONE) __set_fixmap(VSYSCALL_PAGE, physaddr_vsyscall, - vsyscall_mode == NATIVE - ? PAGE_KERNEL_VSYSCALL - : PAGE_KERNEL_VVAR); + __pgprot(vsyscall_pgprot));
BUILD_BUG_ON((unsigned long)__fix_to_virt(VSYSCALL_PAGE) != (unsigned long)VSYSCALL_ADDR); --- a/arch/x86/include/asm/vsyscall.h +++ b/arch/x86/include/asm/vsyscall.h @@ -13,6 +13,7 @@ extern void map_vsyscall(void); */ extern bool emulate_vsyscall(struct pt_regs *regs, unsigned long address); extern bool vsyscall_enabled(void); +extern unsigned long vsyscall_pgprot; #else static inline void map_vsyscall(void) {} static inline bool emulate_vsyscall(struct pt_regs *regs, unsigned long address) --- a/arch/x86/mm/kaiser.c +++ b/arch/x86/mm/kaiser.c @@ -345,7 +345,7 @@ void __init kaiser_init(void) if (vsyscall_enabled()) kaiser_add_user_map_early((void *)VSYSCALL_ADDR, PAGE_SIZE, - __PAGE_KERNEL_VSYSCALL); + vsyscall_pgprot);
for_each_possible_cpu(cpu) { void *percpu_vaddr = __per_cpu_user_mapped_start +
Patches currently in stable-queue which might be from ben.hutchings@codethink.co.uk are
queue-4.4/vsyscall-fix-permissions-for-emulate-mode-with-kaiser-pti.patch queue-4.4/x86-microcode-intel-fix-bdw-late-loading-revision-check.patch
This is a note to let you know that I've just added the patch titled
vsyscall: Fix permissions for emulate mode with KAISER/PTI
to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git%3Ba=su...
The filename of the patch is: vsyscall-fix-permissions-for-emulate-mode-with-kaiser-pti.patch and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let stable@vger.kernel.org know about it.
From ben.hutchings@codethink.co.uk Fri Jan 26 17:35:59 2018
From: Ben Hutchings ben.hutchings@codethink.co.uk Date: Fri, 26 Jan 2018 16:23:02 +0000 Subject: vsyscall: Fix permissions for emulate mode with KAISER/PTI To: Greg Kroah-Hartman gregkh@linuxfoundation.org Cc: Borislav Petkov bp@suse.de, Hugh Dickins hughd@google.com, stable@vger.kernel.org Message-ID: 20180126162302.ei4tmiltl73npmr6@xylophone.i.decadent.org.uk
From: Ben Hutchings ben.hutchings@codethink.co.uk
The backport of KAISER to 4.4 turned vsyscall emulate mode into native mode. Add a vsyscall_pgprot variable to hold the correct page protections, like Borislav and Hugh did for 3.2 and 3.18.
Cc: Borislav Petkov bp@suse.de Cc: Hugh Dickins hughd@google.com Signed-off-by: Ben Hutchings ben.hutchings@codethink.co.uk Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- arch/x86/entry/vsyscall/vsyscall_64.c | 7 ++++--- arch/x86/include/asm/vsyscall.h | 1 + arch/x86/mm/kaiser.c | 2 +- 3 files changed, 6 insertions(+), 4 deletions(-)
--- a/arch/x86/entry/vsyscall/vsyscall_64.c +++ b/arch/x86/entry/vsyscall/vsyscall_64.c @@ -46,6 +46,7 @@ static enum { EMULATE, NATIVE, NONE } vs #else EMULATE; #endif +unsigned long vsyscall_pgprot = __PAGE_KERNEL_VSYSCALL;
static int __init vsyscall_setup(char *str) { @@ -336,11 +337,11 @@ void __init map_vsyscall(void) extern char __vsyscall_page; unsigned long physaddr_vsyscall = __pa_symbol(&__vsyscall_page);
+ if (vsyscall_mode != NATIVE) + vsyscall_pgprot = __PAGE_KERNEL_VVAR; if (vsyscall_mode != NONE) __set_fixmap(VSYSCALL_PAGE, physaddr_vsyscall, - vsyscall_mode == NATIVE - ? PAGE_KERNEL_VSYSCALL - : PAGE_KERNEL_VVAR); + __pgprot(vsyscall_pgprot));
BUILD_BUG_ON((unsigned long)__fix_to_virt(VSYSCALL_PAGE) != (unsigned long)VSYSCALL_ADDR); --- a/arch/x86/include/asm/vsyscall.h +++ b/arch/x86/include/asm/vsyscall.h @@ -13,6 +13,7 @@ extern void map_vsyscall(void); */ extern bool emulate_vsyscall(struct pt_regs *regs, unsigned long address); extern bool vsyscall_enabled(void); +extern unsigned long vsyscall_pgprot; #else static inline void map_vsyscall(void) {} static inline bool emulate_vsyscall(struct pt_regs *regs, unsigned long address) --- a/arch/x86/mm/kaiser.c +++ b/arch/x86/mm/kaiser.c @@ -344,7 +344,7 @@ void __init kaiser_init(void) if (vsyscall_enabled()) kaiser_add_user_map_early((void *)VSYSCALL_ADDR, PAGE_SIZE, - __PAGE_KERNEL_VSYSCALL); + vsyscall_pgprot);
for_each_possible_cpu(cpu) { void *percpu_vaddr = __per_cpu_user_mapped_start +
Patches currently in stable-queue which might be from ben.hutchings@codethink.co.uk are
queue-4.9/vsyscall-fix-permissions-for-emulate-mode-with-kaiser-pti.patch
linux-stable-mirror@lists.linaro.org
-
Ben Hutchings -
Greg Kroah-Hartman -
gregkh＠linuxfoundation.org
-
Hugh Dickins