* Re: [PATCH 4.4] vsyscall: Fix permissions for emulate mode with KAISER/PTI
2018-01-26 16:23 [PATCH 4.4] vsyscall: Fix permissions for emulate mode with KAISER/PTI Ben Hutchings
@ 2018-01-26 16:37 ` Greg Kroah-Hartman
2018-01-26 20:23 ` Hugh Dickins
2018-01-26 16:38 ` Patch "vsyscall: Fix permissions for emulate mode with KAISER/PTI" has been added to the 4.4-stable tree gregkh
2018-01-26 16:38 ` Patch "vsyscall: Fix permissions for emulate mode with KAISER/PTI" has been added to the 4.9-stable tree gregkh
2 siblings, 1 reply; 7+ messages in thread
From: Greg Kroah-Hartman @ 2018-01-26 16:37 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Borislav Petkov, Hugh Dickins, stable
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 4.4] vsyscall: Fix permissions for emulate mode with KAISER/PTI
2018-01-26 16:37 ` Greg Kroah-Hartman
@ 2018-01-26 20:23 ` Hugh Dickins
2018-01-28 12:13 ` Greg Kroah-Hartman
0 siblings, 1 reply; 7+ messages in thread
From: Hugh Dickins @ 2018-01-26 20:23 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Ben Hutchings, Borislav Petkov, Hugh Dickins, stable
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 4.4] vsyscall: Fix permissions for emulate mode with KAISER/PTI
2018-01-26 20:23 ` Hugh Dickins
@ 2018-01-28 12:13 ` Greg Kroah-Hartman
2018-01-28 20:27 ` Hugh Dickins
0 siblings, 1 reply; 7+ messages in thread
From: Greg Kroah-Hartman @ 2018-01-28 12:13 UTC (permalink / raw)
To: Hugh Dickins; +Cc: Ben Hutchings, Borislav Petkov, stable
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 4.4] vsyscall: Fix permissions for emulate mode with KAISER/PTI
2018-01-28 12:13 ` Greg Kroah-Hartman
@ 2018-01-28 20:27 ` Hugh Dickins
0 siblings, 0 replies; 7+ messages in thread
From: Hugh Dickins @ 2018-01-28 20:27 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Ben Hutchings, Borislav Petkov, stable
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Patch "vsyscall: Fix permissions for emulate mode with KAISER/PTI" has been added to the 4.4-stable tree
2018-01-26 16:23 [PATCH 4.4] vsyscall: Fix permissions for emulate mode with KAISER/PTI Ben Hutchings
2018-01-26 16:37 ` Greg Kroah-Hartman
@ 2018-01-26 16:38 ` gregkh
2018-01-26 16:38 ` Patch "vsyscall: Fix permissions for emulate mode with KAISER/PTI" has been added to the 4.9-stable tree gregkh
2 siblings, 0 replies; 7+ messages in thread
From: gregkh @ 2018-01-26 16:38 UTC (permalink / raw)
To: ben.hutchings, bp, gregkh, hughd; +Cc: stable, stable-commits
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;a=summary
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Patch "vsyscall: Fix permissions for emulate mode with KAISER/PTI" has been added to the 4.9-stable tree
2018-01-26 16:23 [PATCH 4.4] vsyscall: Fix permissions for emulate mode with KAISER/PTI Ben Hutchings
2018-01-26 16:37 ` Greg Kroah-Hartman
2018-01-26 16:38 ` Patch "vsyscall: Fix permissions for emulate mode with KAISER/PTI" has been added to the 4.4-stable tree gregkh
@ 2018-01-26 16:38 ` gregkh
2 siblings, 0 replies; 7+ messages in thread
From: gregkh @ 2018-01-26 16:38 UTC (permalink / raw)
To: ben.hutchings, bp, gregkh, hughd; +Cc: stable, stable-commits
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;a=summary
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
^ permalink raw reply [flat|nested] 7+ messages in thread