Re: Linux 4.15-rc7

[Pavel Machek]

On Thu 2018-01-11 15:07:22, Jiri Kosina wrote:
> On Thu, 11 Jan 2018, Pavel Machek wrote:
> 
> > Is anyone working on KPTI for x86-32? SLES11 should still be supported, 
> > and that should have x86-32 version; any chance SUSE can share some 
> > patches?
> 
> We are sharing sources of all our kernels at
> 
>   http://kernel.suse.com/
> 
> If you can find the x86-32 support there, it's yours (hint: you won't).
> 
> Otherwise, you'd either have to wait until we (or someone else) implements 
> it (it's on our list), or implement it yourself.

Hmm. Seems Joerg Roedel from suse sent implementation after all. And
it should boot, mine did not yet. Let me do some testing...

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Linux 4.15-rc7

[Pavel Machek]

On Thu 2018-01-11 15:07:22, Jiri Kosina wrote:
> On Thu, 11 Jan 2018, Pavel Machek wrote:
> 
> > Is anyone working on KPTI for x86-32? SLES11 should still be supported, 
> > and that should have x86-32 version; any chance SUSE can share some 
> > patches?
> 
> We are sharing sources of all our kernels at
> 
>   http://kernel.suse.com/
> 
> If you can find the x86-32 support there, it's yours (hint: you won't).
> 
> Otherwise, you'd either have to wait until we (or someone else) implements 
> it (it's on our list), or implement it yourself.

Hmm. Seems Joerg Roedel from suse sent implementation after all. And
it should boot, mine did not yet. Let me do some testing...

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

kernel page table isolation for x86-32 was Re: Linux 4.15-rc7

[Pavel Machek]

Hi!

> > I'll try to do the right thing. OTOH... I don't like the fact that
> > kernel memory on my machine is currently readable, probably even from
> > javascript.
> 
> Oh, absolutely. I'm just saying that it's probably best to try to
> start from the x86-64 KPTI model, and see how that works for x86-32.

Ok, it should not be too bad. Here's something... getting it to
compile should be easy, getting it to work might be trickier. Not sure
what needs to be done for the LDT.

Pavel

diff --git a/Documentation/x86/pti.txt b/Documentation/x86/pti.txt
index d11eff6..e13e1e5 100644
--- a/Documentation/x86/pti.txt
+++ b/Documentation/x86/pti.txt
@@ -124,7 +124,7 @@ Possible Future Work
boot-time switching.
 
 Testing
-
+===
 
 To test stability of PTI, the following test procedure is recommended,
 ideally doing all of these in parallel:
diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h
index 45a63e0..b0485cc 100644
--- a/arch/x86/entry/calling.h
+++ b/arch/x86/entry/calling.h
@@ -332,6 +332,99 @@ For 32-bit we have the following conventions - kernel is 
built with
 
 #endif
 
+#else
+
+/*
+ * x86-32 kernel page table isolation.
+ */
+#ifdef CONFIG_PAGE_TABLE_ISOLATION
+
+/*
+ * PAGE_TABLE_ISOLATION PGDs are 8k.  Flip bit 12 to switch between the two
+ * halves:
+ */
+#define PTI_SWITCH_PGTABLES_MASK   (1<ip = 0 (placeholder) */
pushl   %eax/* pt_regs->orig_ax */
SAVE_ALL pt_regs_ax=$-ENOSYS/* save rest */
+   SAVE_AND_SWITCH_TO_KERNEL_CR3 scratch_reg=%edx save_reg=%ecx
 
/*
 * SYSENTER doesn't filter flags, so we need to clear NT, AC
@@ -464,6 +467,7 @@ ENTRY(entry_SYSENTER_32)
ALTERNATIVE "testl %eax, %eax; jz .Lsyscall_32_done", \
"jmp .Lsyscall_32_done", X86_FEATURE_XENPV
 
+   RESTORE_CR3 scratch_reg=%edx save_reg=%ecx
 /* Opportunistic SYSEXIT */
TRACE_IRQS_ON   /* User mode traces as IRQs on. */
  

kernel page table isolation for x86-32 was Re: Linux 4.15-rc7

[Pavel Machek]

Hi!

> > I'll try to do the right thing. OTOH... I don't like the fact that
> > kernel memory on my machine is currently readable, probably even from
> > javascript.
> 
> Oh, absolutely. I'm just saying that it's probably best to try to
> start from the x86-64 KPTI model, and see how that works for x86-32.

Ok, it should not be too bad. Here's something... getting it to
compile should be easy, getting it to work might be trickier. Not sure
what needs to be done for the LDT.

Pavel

diff --git a/Documentation/x86/pti.txt b/Documentation/x86/pti.txt
index d11eff6..e13e1e5 100644
--- a/Documentation/x86/pti.txt
+++ b/Documentation/x86/pti.txt
@@ -124,7 +124,7 @@ Possible Future Work
boot-time switching.
 
 Testing
-
+===
 
 To test stability of PTI, the following test procedure is recommended,
 ideally doing all of these in parallel:
diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h
index 45a63e0..b0485cc 100644
--- a/arch/x86/entry/calling.h
+++ b/arch/x86/entry/calling.h
@@ -332,6 +332,99 @@ For 32-bit we have the following conventions - kernel is 
built with
 
 #endif
 
+#else
+
+/*
+ * x86-32 kernel page table isolation.
+ */
+#ifdef CONFIG_PAGE_TABLE_ISOLATION
+
+/*
+ * PAGE_TABLE_ISOLATION PGDs are 8k.  Flip bit 12 to switch between the two
+ * halves:
+ */
+#define PTI_SWITCH_PGTABLES_MASK   (1<
 #include 
 
+#include "calling.h"
+   
.section .entry.text, "ax"
 
 /*
@@ -428,6 +430,7 @@ ENTRY(entry_SYSENTER_32)
pushl   $0  /* pt_regs->ip = 0 (placeholder) */
pushl   %eax/* pt_regs->orig_ax */
SAVE_ALL pt_regs_ax=$-ENOSYS/* save rest */
+   SAVE_AND_SWITCH_TO_KERNEL_CR3 scratch_reg=%edx save_reg=%ecx
 
/*
 * SYSENTER doesn't filter flags, so we need to clear NT, AC
@@ -464,6 +467,7 @@ ENTRY(entry_SYSENTER_32)
ALTERNATIVE "testl %eax, %eax; jz .Lsyscall_32_done", \
"jmp .Lsyscall_32_done", X86_FEATURE_XENPV
 
+   RESTORE_CR3 scratch_reg=%edx save_reg=%ecx
 /* Opportunistic SYSEXIT */
TRACE_IRQS_ON   /* User mode traces as IRQs on. */
movlPT_EIP(%esp), %edx  /* pt_regs->ip */
@@ -539,6 +543,7 @@ ENTRY(entry_INT80_32)
ASM_CLAC
pushl   %eax/* pt_regs->orig_ax */
SAVE_ALL pt_regs_ax=$-ENOSYS/* save rest */
+   SAVE_AND_SWITCH_TO_KERNEL_CR3 scratch_reg=%edx save_reg=%ecx
 
/*
 * User mode is traced as though IRQs are on, and the interrupt gate
@@ -552,6 +557,7 @@ ENTRY(entry_INT80_32)
 
 restore_all:
TRACE_IRQS_IRET
+   RESTORE_CR3 scratch_reg=%eax save_reg=%ecx
 .Lrestore_all_notrace:
 #ifdef CONFIG_X86_ESPFIX32
ALTERNATIVE "jmp .Lrestore_nocheck", "", X86_BUG_ESPFIX
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index e51b65a..a87fb89 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -4,7 +4,7 @@
  *
  *  Copyright (C) 1991, 1992  Linus Torvalds
  *  Copyright (C) 2000, 2001, 2002  Andi Kleen SuSE Labs
- *  Copyright (C) 2000  Pavel Machek 
+ *  Copyright (C) 2000  Pavel Machek SuSE Labs
  *
  * entry.S contains the system-call and fault low-level handling routines.
  *
diff --git a/arch/x86/include/asm/pgtable_32.h 
b/arch/x86/include/asm/pgtable_32.h
index e67c062..1b36e56 100644
--- a/arch/x86/include/asm/pgtable_32.h
+++ b/arch/x86/include/asm/pgtable_32.h
@@ -107,4 +107,78 @@ do {   \
  */
 #define LOWMEM_PAGES 2<<31) - __PAGE_OFFSET) >> PAGE_SHIFT))
 
+#ifdef CONFIG_PAGE_TABLE_ISOLATION
+/*
+ * All top-level PAGE_TABLE_ISOLATION page tables are order-1 pages
+ * (8k-aligned and 8k in size).  The kernel one is at the beginning 4k and
+ * the user one is in the last 4k.  To switch between them, you
+ * just need to flip the 12th bit in their addresses.
+ */
+#define PTI_PGTABLE_SWITCH_BIT PAGE_SHIFT
+
+#ifndef __ASSEMBLY__
+/*
+ * This generates better code than the inline assembly in
+ * __set_bit().
+ */
+static inline void *ptr_set_bit(void *ptr, int bit)
+{
+   unsigned long __ptr = (unsigned long)ptr;
+
+   __ptr |= BIT(bit);
+   return (void *)__ptr;
+}
+static inline void *ptr_clear_bit(void *ptr, int bit)
+{
+   unsigned long __ptr = (unsigned long)ptr;
+
+   __ptr &= ~BIT(bit);
+   return (void *)__ptr;
+}
+
+static inline pgd_t *kernel_to_user_pgdp(pgd_t *pgdp)
+{
+   return ptr_set_bit(pgdp, PTI_PGTABLE_SWITCH_BIT);
+}
+
+static inline pgd_t *user_to_kernel_pgdp(pgd_t *pgdp)
+{
+   return ptr_clear_bit(pgdp, PTI_PGTABLE_SWITCH_BIT);
+}
+
+static inline p4d_t *kernel_to_user_p4dp(p4d_t *p4dp)
+{
+   return ptr_set_bit(p4dp, PTI_PGTABLE_SWITCH_BIT);
+}
+
+static inline p4d_t *user_to_kernel_p4dp(p4d_t *p4dp)
+{
+   return ptr_clear_bit(p4dp, 

Re: Linux 4.15-rc7

[vcaputo]

On Fri, Jan 12, 2018 at 11:08:58PM +0100, Arnd Bergmann wrote:
> On Fri, Jan 12, 2018 at 11:04 PM,   wrote:
> > On Fri, Jan 12, 2018 at 09:11:38PM +0100, Arnd Bergmann wrote:
> >
> >> - I haven't found a definite answer on whether Netburst-based CPUs
> >>   are affected by meltdown at all. Some people claim it's affected,
> >>   others say it's not. If the code from https://github.com/IAIK/meltdown
> >>   is successful on your Celeron D, then we know it's affected, if not,
> >>   then you could decide to not care about KPTI (Spectre would still
> >>   be an issue).
> >>
> >
> > I tried that when the code was first made public, but libkdump doesn't
> > support 32-bit; it's full of 64-bit register use in the assembly bits.
> 
> Apparently 32-bit support was added on Wednesday, maybe you
> can try again with today's version.
> 

Thanks for informing me of this, I hadn't noticed.

I just tried it out, and confirmed the Celeron D is vulnerable to
meltdown.

Regards,
Vito Caputo

Re: Linux 4.15-rc7

[vcaputo]

On Fri, Jan 12, 2018 at 11:08:58PM +0100, Arnd Bergmann wrote:
> On Fri, Jan 12, 2018 at 11:04 PM,   wrote:
> > On Fri, Jan 12, 2018 at 09:11:38PM +0100, Arnd Bergmann wrote:
> >
> >> - I haven't found a definite answer on whether Netburst-based CPUs
> >>   are affected by meltdown at all. Some people claim it's affected,
> >>   others say it's not. If the code from https://github.com/IAIK/meltdown
> >>   is successful on your Celeron D, then we know it's affected, if not,
> >>   then you could decide to not care about KPTI (Spectre would still
> >>   be an issue).
> >>
> >
> > I tried that when the code was first made public, but libkdump doesn't
> > support 32-bit; it's full of 64-bit register use in the assembly bits.
> 
> Apparently 32-bit support was added on Wednesday, maybe you
> can try again with today's version.
> 

Thanks for informing me of this, I hadn't noticed.

I just tried it out, and confirmed the Celeron D is vulnerable to
meltdown.

Regards,
Vito Caputo

Re: Linux 4.15-rc7

[Arnd Bergmann]

On Fri, Jan 12, 2018 at 11:04 PM,   wrote:
> On Fri, Jan 12, 2018 at 09:11:38PM +0100, Arnd Bergmann wrote:
>
>> - I haven't found a definite answer on whether Netburst-based CPUs
>>   are affected by meltdown at all. Some people claim it's affected,
>>   others say it's not. If the code from https://github.com/IAIK/meltdown
>>   is successful on your Celeron D, then we know it's affected, if not,
>>   then you could decide to not care about KPTI (Spectre would still
>>   be an issue).
>>
>
> I tried that when the code was first made public, but libkdump doesn't
> support 32-bit; it's full of 64-bit register use in the assembly bits.

Apparently 32-bit support was added on Wednesday, maybe you
can try again with today's version.

  Arnd

Re: Linux 4.15-rc7

[Arnd Bergmann]

On Fri, Jan 12, 2018 at 11:04 PM,   wrote:
> On Fri, Jan 12, 2018 at 09:11:38PM +0100, Arnd Bergmann wrote:
>
>> - I haven't found a definite answer on whether Netburst-based CPUs
>>   are affected by meltdown at all. Some people claim it's affected,
>>   others say it's not. If the code from https://github.com/IAIK/meltdown
>>   is successful on your Celeron D, then we know it's affected, if not,
>>   then you could decide to not care about KPTI (Spectre would still
>>   be an issue).
>>
>
> I tried that when the code was first made public, but libkdump doesn't
> support 32-bit; it's full of 64-bit register use in the assembly bits.

Apparently 32-bit support was added on Wednesday, maybe you
can try again with today's version.

  Arnd

Re: Linux 4.15-rc7

[vcaputo]

On Fri, Jan 12, 2018 at 09:11:38PM +0100, Arnd Bergmann wrote:
> On Fri, Jan 12, 2018 at 6:20 PM,   wrote:
> > On Fri, Jan 12, 2018 at 02:23:20PM +0100, Arnd Bergmann wrote:
> 
> >> Could you be more specific which 32-bit x86 chips you have that are
> >> affected by Meltdown? Do you mean pre-2004 Pentiums or Core-Duo
> >> laptops? I would guess that Cyrix/Natsemi/AMD 6x86/MediaGX/Geode
> >> and AMD NexGen K6/K7 also affected by Spectre but probably not
> >> Meltdown, and most other 32-bit microarchitectures seem to be purely
> >> in-order.
> >>
> >
> > I have some Celeron D, 4GiB dedicated servers with a 32-bit stack.
> > They've proven to be very reliable boxes, and are the most affordable
> > baremetal x86 machines I've found.  I'd appreciate a PTI implementation
> > on them.
> 
> That's an interesting setup for a number of reasons:
> 
> - Celeron D are mostly 64-bit CPUs, but it depends on the particular
>   model/stepping, so if you have a couple of them, you might be able to
>   avoid the meltdown bug by running a 64-bit kernel with KPTI at least on
>   some of them, or trivially replace the CPU on others. This usually
>   works without changing user space, and tends to result in a faster
>   system than running a 32-bit kernel as you avoid highmem.
>

This may be possible, I'll need to try booting a x86_64 kernel on one
and see.  I would rather not change all of userspace.

> - I haven't found a definite answer on whether Netburst-based CPUs
>   are affected by meltdown at all. Some people claim it's affected,
>   others say it's not. If the code from https://github.com/IAIK/meltdown
>   is successful on your Celeron D, then we know it's affected, if not,
>   then you could decide to not care about KPTI (Spectre would still
>   be an issue).
>

I tried that when the code was first made public, but libkdump doesn't
support 32-bit; it's full of 64-bit register use in the assembly bits.

> - A 32-bit system running with mostly highmem (only the low 768 MB
>   out of 4GB are directly mapped) means some of the exploits are
>   harder to do in practice, as most of the page cache is not visible
>   in the kernel, and reading data from other processes will fail more
>   often that succeed.
>

Well that's good news.

> - Economically, it seems barely worth running these if you pay for
>   the electricity: the CPU costs a few dollars/euros, it only takes
>   a couple of weeks of continuous operation to exceed that in
>   operating cost. Replacing the mainboard with a modern low end
>   all-in-one board at 10W might pay off within a year. If you don't pay
>   for electricity, that obviously doesn't work.
> 

I don't pay for the electricity, these are old dedicated servers hosted
by a third party.  Not my hardware, and any more modern dedicated x86
servers I've found are substantially more expensive and always SMP.

This particular hosting provider has tried selling me upgrades to their
current low-end offering (which is still SMP), the price basically
doubles.  These boxes are mostly idle, performing just personal email
and ssh duties.  For this situation reliability and security is the
priority, power efficiency and performance are not.

Thanks,
Vito Caputo

Re: Linux 4.15-rc7

[vcaputo]

On Fri, Jan 12, 2018 at 09:11:38PM +0100, Arnd Bergmann wrote:
> On Fri, Jan 12, 2018 at 6:20 PM,   wrote:
> > On Fri, Jan 12, 2018 at 02:23:20PM +0100, Arnd Bergmann wrote:
> 
> >> Could you be more specific which 32-bit x86 chips you have that are
> >> affected by Meltdown? Do you mean pre-2004 Pentiums or Core-Duo
> >> laptops? I would guess that Cyrix/Natsemi/AMD 6x86/MediaGX/Geode
> >> and AMD NexGen K6/K7 also affected by Spectre but probably not
> >> Meltdown, and most other 32-bit microarchitectures seem to be purely
> >> in-order.
> >>
> >
> > I have some Celeron D, 4GiB dedicated servers with a 32-bit stack.
> > They've proven to be very reliable boxes, and are the most affordable
> > baremetal x86 machines I've found.  I'd appreciate a PTI implementation
> > on them.
> 
> That's an interesting setup for a number of reasons:
> 
> - Celeron D are mostly 64-bit CPUs, but it depends on the particular
>   model/stepping, so if you have a couple of them, you might be able to
>   avoid the meltdown bug by running a 64-bit kernel with KPTI at least on
>   some of them, or trivially replace the CPU on others. This usually
>   works without changing user space, and tends to result in a faster
>   system than running a 32-bit kernel as you avoid highmem.
>

This may be possible, I'll need to try booting a x86_64 kernel on one
and see.  I would rather not change all of userspace.

> - I haven't found a definite answer on whether Netburst-based CPUs
>   are affected by meltdown at all. Some people claim it's affected,
>   others say it's not. If the code from https://github.com/IAIK/meltdown
>   is successful on your Celeron D, then we know it's affected, if not,
>   then you could decide to not care about KPTI (Spectre would still
>   be an issue).
>

I tried that when the code was first made public, but libkdump doesn't
support 32-bit; it's full of 64-bit register use in the assembly bits.

> - A 32-bit system running with mostly highmem (only the low 768 MB
>   out of 4GB are directly mapped) means some of the exploits are
>   harder to do in practice, as most of the page cache is not visible
>   in the kernel, and reading data from other processes will fail more
>   often that succeed.
>

Well that's good news.

> - Economically, it seems barely worth running these if you pay for
>   the electricity: the CPU costs a few dollars/euros, it only takes
>   a couple of weeks of continuous operation to exceed that in
>   operating cost. Replacing the mainboard with a modern low end
>   all-in-one board at 10W might pay off within a year. If you don't pay
>   for electricity, that obviously doesn't work.
> 

I don't pay for the electricity, these are old dedicated servers hosted
by a third party.  Not my hardware, and any more modern dedicated x86
servers I've found are substantially more expensive and always SMP.

This particular hosting provider has tried selling me upgrades to their
current low-end offering (which is still SMP), the price basically
doubles.  These boxes are mostly idle, performing just personal email
and ssh duties.  For this situation reliability and security is the
priority, power efficiency and performance are not.

Thanks,
Vito Caputo

Re: Linux 4.15-rc7

[Pavel Machek]

On Fri 2018-01-12 11:44:48, Linus Torvalds wrote:
> On Fri, Jan 12, 2018 at 11:38 AM, Pavel Machek  wrote:
> >
> > I'll try to do the right thing. OTOH... I don't like the fact that
> > kernel memory on my machine is currently readable, probably even from
> > javascript.
> 
> Oh, absolutely. I'm just saying that it's probably best to try to
> start from the x86-64 KPTI model, and see how that works for x86-32.
> 
> Maybe some of the 4G:4G entry code could come in handy as a "these are
> the issues" kind of thing.

Ok, so I do have the diff that compiles, and it is 300 lines. Those
will be extremely tricky 300 lines, but...

> > I tried disabling CPU caches. Just like that, off, boom. My system
> > will not survive that, and it looks like 100x slowdown.
> 
> Yeah, no. That is not a realistic thing to do on any hardware since
> the PPro, I'm afraid.

What is special about PPro?

Well -- cache off kind of is what I want -- kills Spectre _and_
Meltdown ;-), attacking close to the fundametal issue. And it really
should be doable on UP system, right?

I guess I should re-try with plain VGA console, not framebuffer.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Linux 4.15-rc7

[Pavel Machek]

On Fri 2018-01-12 11:44:48, Linus Torvalds wrote:
> On Fri, Jan 12, 2018 at 11:38 AM, Pavel Machek  wrote:
> >
> > I'll try to do the right thing. OTOH... I don't like the fact that
> > kernel memory on my machine is currently readable, probably even from
> > javascript.
> 
> Oh, absolutely. I'm just saying that it's probably best to try to
> start from the x86-64 KPTI model, and see how that works for x86-32.
> 
> Maybe some of the 4G:4G entry code could come in handy as a "these are
> the issues" kind of thing.

Ok, so I do have the diff that compiles, and it is 300 lines. Those
will be extremely tricky 300 lines, but...

> > I tried disabling CPU caches. Just like that, off, boom. My system
> > will not survive that, and it looks like 100x slowdown.
> 
> Yeah, no. That is not a realistic thing to do on any hardware since
> the PPro, I'm afraid.

What is special about PPro?

Well -- cache off kind of is what I want -- kills Spectre _and_
Meltdown ;-), attacking close to the fundametal issue. And it really
should be doable on UP system, right?

I guess I should re-try with plain VGA console, not framebuffer.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Linux 4.15-rc7

[Arnd Bergmann]

On Fri, Jan 12, 2018 at 6:20 PM,   wrote:
> On Fri, Jan 12, 2018 at 02:23:20PM +0100, Arnd Bergmann wrote:

>> Could you be more specific which 32-bit x86 chips you have that are
>> affected by Meltdown? Do you mean pre-2004 Pentiums or Core-Duo
>> laptops? I would guess that Cyrix/Natsemi/AMD 6x86/MediaGX/Geode
>> and AMD NexGen K6/K7 also affected by Spectre but probably not
>> Meltdown, and most other 32-bit microarchitectures seem to be purely
>> in-order.
>>
>
> I have some Celeron D, 4GiB dedicated servers with a 32-bit stack.
> They've proven to be very reliable boxes, and are the most affordable
> baremetal x86 machines I've found.  I'd appreciate a PTI implementation
> on them.

That's an interesting setup for a number of reasons:

- Celeron D are mostly 64-bit CPUs, but it depends on the particular
  model/stepping, so if you have a couple of them, you might be able to
  avoid the meltdown bug by running a 64-bit kernel with KPTI at least on
  some of them, or trivially replace the CPU on others. This usually
  works without changing user space, and tends to result in a faster
  system than running a 32-bit kernel as you avoid highmem.
- I haven't found a definite answer on whether Netburst-based CPUs
  are affected by meltdown at all. Some people claim it's affected,
  others say it's not. If the code from https://github.com/IAIK/meltdown
  is successful on your Celeron D, then we know it's affected, if not,
  then you could decide to not care about KPTI (Spectre would still
  be an issue).
- A 32-bit system running with mostly highmem (only the low 768 MB
  out of 4GB are directly mapped) means some of the exploits are
  harder to do in practice, as most of the page cache is not visible
  in the kernel, and reading data from other processes will fail more
  often that succeed.
- Economically, it seems barely worth running these if you pay for
  the electricity: the CPU costs a few dollars/euros, it only takes
  a couple of weeks of continuous operation to exceed that in
  operating cost. Replacing the mainboard with a modern low end
  all-in-one board at 10W might pay off within a year. If you don't pay
  for electricity, that obviously doesn't work.

 Arnd

Re: Linux 4.15-rc7

[Arnd Bergmann]

On Fri, Jan 12, 2018 at 6:20 PM,   wrote:
> On Fri, Jan 12, 2018 at 02:23:20PM +0100, Arnd Bergmann wrote:

>> Could you be more specific which 32-bit x86 chips you have that are
>> affected by Meltdown? Do you mean pre-2004 Pentiums or Core-Duo
>> laptops? I would guess that Cyrix/Natsemi/AMD 6x86/MediaGX/Geode
>> and AMD NexGen K6/K7 also affected by Spectre but probably not
>> Meltdown, and most other 32-bit microarchitectures seem to be purely
>> in-order.
>>
>
> I have some Celeron D, 4GiB dedicated servers with a 32-bit stack.
> They've proven to be very reliable boxes, and are the most affordable
> baremetal x86 machines I've found.  I'd appreciate a PTI implementation
> on them.

That's an interesting setup for a number of reasons:

- Celeron D are mostly 64-bit CPUs, but it depends on the particular
  model/stepping, so if you have a couple of them, you might be able to
  avoid the meltdown bug by running a 64-bit kernel with KPTI at least on
  some of them, or trivially replace the CPU on others. This usually
  works without changing user space, and tends to result in a faster
  system than running a 32-bit kernel as you avoid highmem.
- I haven't found a definite answer on whether Netburst-based CPUs
  are affected by meltdown at all. Some people claim it's affected,
  others say it's not. If the code from https://github.com/IAIK/meltdown
  is successful on your Celeron D, then we know it's affected, if not,
  then you could decide to not care about KPTI (Spectre would still
  be an issue).
- A 32-bit system running with mostly highmem (only the low 768 MB
  out of 4GB are directly mapped) means some of the exploits are
  harder to do in practice, as most of the page cache is not visible
  in the kernel, and reading data from other processes will fail more
  often that succeed.
- Economically, it seems barely worth running these if you pay for
  the electricity: the CPU costs a few dollars/euros, it only takes
  a couple of weeks of continuous operation to exceed that in
  operating cost. Replacing the mainboard with a modern low end
  all-in-one board at 10W might pay off within a year. If you don't pay
  for electricity, that obviously doesn't work.

 Arnd

Re: Linux 4.15-rc7

[Linus Torvalds]

On Fri, Jan 12, 2018 at 11:38 AM, Pavel Machek  wrote:
>
> I'll try to do the right thing. OTOH... I don't like the fact that
> kernel memory on my machine is currently readable, probably even from
> javascript.

Oh, absolutely. I'm just saying that it's probably best to try to
start from the x86-64 KPTI model, and see how that works for x86-32.

Maybe some of the 4G:4G entry code could come in handy as a "these are
the issues" kind of thing.

> I tried disabling CPU caches. Just like that, off, boom. My system
> will not survive that, and it looks like 100x slowdown.

Yeah, no. That is not a realistic thing to do on any hardware since
the PPro, I'm afraid.

   Linus

Re: Linux 4.15-rc7

[Linus Torvalds]

On Fri, Jan 12, 2018 at 11:38 AM, Pavel Machek  wrote:
>
> I'll try to do the right thing. OTOH... I don't like the fact that
> kernel memory on my machine is currently readable, probably even from
> javascript.

Oh, absolutely. I'm just saying that it's probably best to try to
start from the x86-64 KPTI model, and see how that works for x86-32.

Maybe some of the 4G:4G entry code could come in handy as a "these are
the issues" kind of thing.

> I tried disabling CPU caches. Just like that, off, boom. My system
> will not survive that, and it looks like 100x slowdown.

Yeah, no. That is not a realistic thing to do on any hardware since
the PPro, I'm afraid.

   Linus

Re: Linux 4.15-rc7

[Pavel Machek]

On Fri 2018-01-12 09:34:03, Linus Torvalds wrote:
> On Fri, Jan 12, 2018 at 5:23 AM, Arnd Bergmann  wrote:
> >
> > However, there is an important difference between KPTI and X86_4G:
> > The former unmaps the kernel pages from the user space page tables,
> > but keeps both the linear mapping and the user pages visible in
> > kernel mode, while the latter must have also unmapped user space
> > pages from kernel mode, requiring a more expensive get_user/put_user
> > implementation.
> 
> Indeed. And I think that the 4G:4G patches do things wrong.

Yeah. But if there's copy around for something recent, I'd still like
to see it.

> People are already complaining about the PTI costs. Separating user
> space entirely is much much worse, and makes all user accesses from
> kernel space too painful for words.
> 
> Honestly, I didn't merge the old 4G:4G patches originally, and I'm not
> going to merge them this time around either.

I'll try to do the right thing. OTOH... I don't like the fact that
kernel memory on my machine is currently readable, probably even from
javascript.

I tried disabling CPU caches. Just like that, off, boom. My system
will not survive that, and it looks like 100x slowdown. So 2x slowdown
would be an improvement (and 4G:4G can probably do better than that).

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Linux 4.15-rc7

[Pavel Machek]

On Fri 2018-01-12 09:34:03, Linus Torvalds wrote:
> On Fri, Jan 12, 2018 at 5:23 AM, Arnd Bergmann  wrote:
> >
> > However, there is an important difference between KPTI and X86_4G:
> > The former unmaps the kernel pages from the user space page tables,
> > but keeps both the linear mapping and the user pages visible in
> > kernel mode, while the latter must have also unmapped user space
> > pages from kernel mode, requiring a more expensive get_user/put_user
> > implementation.
> 
> Indeed. And I think that the 4G:4G patches do things wrong.

Yeah. But if there's copy around for something recent, I'd still like
to see it.

> People are already complaining about the PTI costs. Separating user
> space entirely is much much worse, and makes all user accesses from
> kernel space too painful for words.
> 
> Honestly, I didn't merge the old 4G:4G patches originally, and I'm not
> going to merge them this time around either.

I'll try to do the right thing. OTOH... I don't like the fact that
kernel memory on my machine is currently readable, probably even from
javascript.

I tried disabling CPU caches. Just like that, off, boom. My system
will not survive that, and it looks like 100x slowdown. So 2x slowdown
would be an improvement (and 4G:4G can probably do better than that).

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Linux 4.15-rc7

[Linus Torvalds]

On Fri, Jan 12, 2018 at 5:23 AM, Arnd Bergmann  wrote:
>
> However, there is an important difference between KPTI and X86_4G:
> The former unmaps the kernel pages from the user space page tables,
> but keeps both the linear mapping and the user pages visible in
> kernel mode, while the latter must have also unmapped user space
> pages from kernel mode, requiring a more expensive get_user/put_user
> implementation.

Indeed. And I think that the 4G:4G patches do things wrong.

People are already complaining about the PTI costs. Separating user
space entirely is much much worse, and makes all user accesses from
kernel space too painful for words.

Honestly, I didn't merge the old 4G:4G patches originally, and I'm not
going to merge them this time around either.

 Linus

Re: Linux 4.15-rc7

[Linus Torvalds]

On Fri, Jan 12, 2018 at 5:23 AM, Arnd Bergmann  wrote:
>
> However, there is an important difference between KPTI and X86_4G:
> The former unmaps the kernel pages from the user space page tables,
> but keeps both the linear mapping and the user pages visible in
> kernel mode, while the latter must have also unmapped user space
> pages from kernel mode, requiring a more expensive get_user/put_user
> implementation.

Indeed. And I think that the 4G:4G patches do things wrong.

People are already complaining about the PTI costs. Separating user
space entirely is much much worse, and makes all user accesses from
kernel space too painful for words.

Honestly, I didn't merge the old 4G:4G patches originally, and I'm not
going to merge them this time around either.

 Linus

Re: Linux 4.15-rc7

[vcaputo]

On Fri, Jan 12, 2018 at 02:23:20PM +0100, Arnd Bergmann wrote:
> On Fri, Jan 12, 2018 at 12:06 PM, Pavel Machek  wrote:
> > Hi!
> >
> >> Wasn't/Isn't the 4G/4G  memory layout for 32 bits essentially KPTI?
> >
> > Good point. Is that still supported? Was it ever?
> >
> > Umm. I seem to recall that 4G/4G layout was out of tree but never
> > merged.
> 
> I think that's correct: it was in RHEL3 and RHEL4 but never merged
> upstream.
> 
> However, there is an important difference between KPTI and X86_4G:
> The former unmaps the kernel pages from the user space page tables,
> but keeps both the linear mapping and the user pages visible in
> kernel mode, while the latter must have also unmapped user space
> pages from kernel mode, requiring a more expensive get_user/put_user
> implementation.
> 
> Kees mentioned an idea to also unmap user pages from kernel
> mode as an additional safeguard on top of KPTI, which would get
> it even closer to the X86_4G implementation:
> https://outflux.net/blog/archives/2018/01/04/smep-emulation-in-pti/
> 
> Could you be more specific which 32-bit x86 chips you have that are
> affected by Meltdown? Do you mean pre-2004 Pentiums or Core-Duo
> laptops? I would guess that Cyrix/Natsemi/AMD 6x86/MediaGX/Geode
> and AMD NexGen K6/K7 also affected by Spectre but probably not
> Meltdown, and most other 32-bit microarchitectures seem to be purely
> in-order.
> 

I have some Celeron D, 4GiB dedicated servers with a 32-bit stack.
They've proven to be very reliable boxes, and are the most affordable
baremetal x86 machines I've found.  I'd appreciate a PTI implementation
on them.

Thanks,
Vito Caputo

Re: Linux 4.15-rc7

[vcaputo]

On Fri, Jan 12, 2018 at 02:23:20PM +0100, Arnd Bergmann wrote:
> On Fri, Jan 12, 2018 at 12:06 PM, Pavel Machek  wrote:
> > Hi!
> >
> >> Wasn't/Isn't the 4G/4G  memory layout for 32 bits essentially KPTI?
> >
> > Good point. Is that still supported? Was it ever?
> >
> > Umm. I seem to recall that 4G/4G layout was out of tree but never
> > merged.
> 
> I think that's correct: it was in RHEL3 and RHEL4 but never merged
> upstream.
> 
> However, there is an important difference between KPTI and X86_4G:
> The former unmaps the kernel pages from the user space page tables,
> but keeps both the linear mapping and the user pages visible in
> kernel mode, while the latter must have also unmapped user space
> pages from kernel mode, requiring a more expensive get_user/put_user
> implementation.
> 
> Kees mentioned an idea to also unmap user pages from kernel
> mode as an additional safeguard on top of KPTI, which would get
> it even closer to the X86_4G implementation:
> https://outflux.net/blog/archives/2018/01/04/smep-emulation-in-pti/
> 
> Could you be more specific which 32-bit x86 chips you have that are
> affected by Meltdown? Do you mean pre-2004 Pentiums or Core-Duo
> laptops? I would guess that Cyrix/Natsemi/AMD 6x86/MediaGX/Geode
> and AMD NexGen K6/K7 also affected by Spectre but probably not
> Meltdown, and most other 32-bit microarchitectures seem to be purely
> in-order.
> 

I have some Celeron D, 4GiB dedicated servers with a 32-bit stack.
They've proven to be very reliable boxes, and are the most affordable
baremetal x86 machines I've found.  I'd appreciate a PTI implementation
on them.

Thanks,
Vito Caputo

Re: Linux 4.15-rc7

[Pavel Machek]

Hi!

> >> Wasn't/Isn't the 4G/4G  memory layout for 32 bits essentially KPTI?
> >
> > Good point. Is that still supported? Was it ever?
> >
> > Umm. I seem to recall that 4G/4G layout was out of tree but never
> > merged.
> 
> I think that's correct: it was in RHEL3 and RHEL4 but never merged
> upstream.

Too bad.

> However, there is an important difference between KPTI and X86_4G:
> The former unmaps the kernel pages from the user space page tables,
> but keeps both the linear mapping and the user pages visible in
> kernel mode, while the latter must have also unmapped user space
> pages from kernel mode, requiring a more expensive get_user/put_user
> implementation.
> 
> Kees mentioned an idea to also unmap user pages from kernel
> mode as an additional safeguard on top of KPTI, which would get
> it even closer to the X86_4G implementation:
> https://outflux.net/blog/archives/2018/01/04/smep-emulation-in-pti/

Well, I guess at this point I'm looking for a good place to start from...

> Could you be more specific which 32-bit x86 chips you have that are
> affected by Meltdown? Do you mean pre-2004 Pentiums or Core-Duo
> laptops? I would guess that Cyrix/Natsemi/AMD 6x86/MediaGX/Geode
> and AMD NexGen K6/K7 also affected by Spectre but probably not
> Meltdown, and most other 32-bit microarchitectures seem to be purely
> in-order.

I do have Core Solo here'd like to keep working (and useful for web
browsing). Then there's Pentium M. Occasionaly I run 32-bit kernels on
modern machines for testing.

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Linux 4.15-rc7

[Pavel Machek]

Hi!

> >> Wasn't/Isn't the 4G/4G  memory layout for 32 bits essentially KPTI?
> >
> > Good point. Is that still supported? Was it ever?
> >
> > Umm. I seem to recall that 4G/4G layout was out of tree but never
> > merged.
> 
> I think that's correct: it was in RHEL3 and RHEL4 but never merged
> upstream.

Too bad.

> However, there is an important difference between KPTI and X86_4G:
> The former unmaps the kernel pages from the user space page tables,
> but keeps both the linear mapping and the user pages visible in
> kernel mode, while the latter must have also unmapped user space
> pages from kernel mode, requiring a more expensive get_user/put_user
> implementation.
> 
> Kees mentioned an idea to also unmap user pages from kernel
> mode as an additional safeguard on top of KPTI, which would get
> it even closer to the X86_4G implementation:
> https://outflux.net/blog/archives/2018/01/04/smep-emulation-in-pti/

Well, I guess at this point I'm looking for a good place to start from...

> Could you be more specific which 32-bit x86 chips you have that are
> affected by Meltdown? Do you mean pre-2004 Pentiums or Core-Duo
> laptops? I would guess that Cyrix/Natsemi/AMD 6x86/MediaGX/Geode
> and AMD NexGen K6/K7 also affected by Spectre but probably not
> Meltdown, and most other 32-bit microarchitectures seem to be purely
> in-order.

I do have Core Solo here'd like to keep working (and useful for web
browsing). Then there's Pentium M. Occasionaly I run 32-bit kernels on
modern machines for testing.

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Linux 4.15-rc7

[Arnd Bergmann]

On Fri, Jan 12, 2018 at 12:06 PM, Pavel Machek  wrote:
> Hi!
>
>> Wasn't/Isn't the 4G/4G  memory layout for 32 bits essentially KPTI?
>
> Good point. Is that still supported? Was it ever?
>
> Umm. I seem to recall that 4G/4G layout was out of tree but never
> merged.

I think that's correct: it was in RHEL3 and RHEL4 but never merged
upstream.

However, there is an important difference between KPTI and X86_4G:
The former unmaps the kernel pages from the user space page tables,
but keeps both the linear mapping and the user pages visible in
kernel mode, while the latter must have also unmapped user space
pages from kernel mode, requiring a more expensive get_user/put_user
implementation.

Kees mentioned an idea to also unmap user pages from kernel
mode as an additional safeguard on top of KPTI, which would get
it even closer to the X86_4G implementation:
https://outflux.net/blog/archives/2018/01/04/smep-emulation-in-pti/

Could you be more specific which 32-bit x86 chips you have that are
affected by Meltdown? Do you mean pre-2004 Pentiums or Core-Duo
laptops? I would guess that Cyrix/Natsemi/AMD 6x86/MediaGX/Geode
and AMD NexGen K6/K7 also affected by Spectre but probably not
Meltdown, and most other 32-bit microarchitectures seem to be purely
in-order.

Arnd

Re: Linux 4.15-rc7

[Arnd Bergmann]

On Fri, Jan 12, 2018 at 12:06 PM, Pavel Machek  wrote:
> Hi!
>
>> Wasn't/Isn't the 4G/4G  memory layout for 32 bits essentially KPTI?
>
> Good point. Is that still supported? Was it ever?
>
> Umm. I seem to recall that 4G/4G layout was out of tree but never
> merged.

I think that's correct: it was in RHEL3 and RHEL4 but never merged
upstream.

However, there is an important difference between KPTI and X86_4G:
The former unmaps the kernel pages from the user space page tables,
but keeps both the linear mapping and the user pages visible in
kernel mode, while the latter must have also unmapped user space
pages from kernel mode, requiring a more expensive get_user/put_user
implementation.

Kees mentioned an idea to also unmap user pages from kernel
mode as an additional safeguard on top of KPTI, which would get
it even closer to the X86_4G implementation:
https://outflux.net/blog/archives/2018/01/04/smep-emulation-in-pti/

Could you be more specific which 32-bit x86 chips you have that are
affected by Meltdown? Do you mean pre-2004 Pentiums or Core-Duo
laptops? I would guess that Cyrix/Natsemi/AMD 6x86/MediaGX/Geode
and AMD NexGen K6/K7 also affected by Spectre but probably not
Meltdown, and most other 32-bit microarchitectures seem to be purely
in-order.

Arnd

Re: Linux 4.15-rc7

[Pavel Machek]

Hi!

> Wasn't/Isn't the 4G/4G  memory layout for 32 bits essentially KPTI?

Good point. Is that still supported? Was it ever?

Umm. I seem to recall that 4G/4G layout was out of tree but never
merged.

High Memory Support
  1. off (NOHIGHMEM)
2. 4GB (HIGHMEM4G)
> 3. 64GB (HIGHMEM64G)
choice[1-3]: 3
Memory split
> 1. 3G/1G user/kernel split (VMSPLIT_3G) (NEW)
  2. 2G/2G user/kernel split (VMSPLIT_2G)
  3. 1G/3G user/kernel split (VMSPLIT_1G)
choice[1-3?]:

Does anyone have recent patches?

Best regards,
Pavel

> On Thu, Jan 11, 2018 at 12:32 AM, Pavel Machek  wrote:
> > Hi!
> >
> >> The one thing I want to do now that Meltdown and Spectre are public,
> >> is to give a *big* shout-out to the x86 people, and Thomas Gleixner in
> >> particular for really being on top of this.  It's been one huge
> >> annoyance, and honestly, Thomas really went over and beyond in this
> >> whole mess.  A lot of other people have obviously been involved too,
> >
> > As I understand it: KPTI prevents Meltdown attack on x86-64, but
> > Spectre means even x86-64 is not expected to be safe?
> >
> > Ok, so Meltdown is public... And I still have some nice 32-bit
> > machines I'd like to keep working.
> >
> > Proof of concept is out, https://github.com/IAIK/meltdown/ .
> >
> > Is anyone working on KPTI for x86-32? SLES11 should still be
> > supported, and that should have x86-32 version; any chance SUSE can
> > share some patches?
> >
> > Thanks,
> > 
> > Pavel
> > --
> > (english) http://www.livejournal.com/~pavelmachek
> > (cesky, pictures) 
> > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Linux 4.15-rc7

[Pavel Machek]

Hi!

> Wasn't/Isn't the 4G/4G  memory layout for 32 bits essentially KPTI?

Good point. Is that still supported? Was it ever?

Umm. I seem to recall that 4G/4G layout was out of tree but never
merged.

High Memory Support
  1. off (NOHIGHMEM)
2. 4GB (HIGHMEM4G)
> 3. 64GB (HIGHMEM64G)
choice[1-3]: 3
Memory split
> 1. 3G/1G user/kernel split (VMSPLIT_3G) (NEW)
  2. 2G/2G user/kernel split (VMSPLIT_2G)
  3. 1G/3G user/kernel split (VMSPLIT_1G)
choice[1-3?]:

Does anyone have recent patches?

Best regards,
Pavel

> On Thu, Jan 11, 2018 at 12:32 AM, Pavel Machek  wrote:
> > Hi!
> >
> >> The one thing I want to do now that Meltdown and Spectre are public,
> >> is to give a *big* shout-out to the x86 people, and Thomas Gleixner in
> >> particular for really being on top of this.  It's been one huge
> >> annoyance, and honestly, Thomas really went over and beyond in this
> >> whole mess.  A lot of other people have obviously been involved too,
> >
> > As I understand it: KPTI prevents Meltdown attack on x86-64, but
> > Spectre means even x86-64 is not expected to be safe?
> >
> > Ok, so Meltdown is public... And I still have some nice 32-bit
> > machines I'd like to keep working.
> >
> > Proof of concept is out, https://github.com/IAIK/meltdown/ .
> >
> > Is anyone working on KPTI for x86-32? SLES11 should still be
> > supported, and that should have x86-32 version; any chance SUSE can
> > share some patches?
> >
> > Thanks,
> > 
> > Pavel
> > --
> > (english) http://www.livejournal.com/~pavelmachek
> > (cesky, pictures) 
> > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Linux 4.15-rc7

[Jiri Kosina]

On Thu, 11 Jan 2018, Pavel Machek wrote:

> Is anyone working on KPTI for x86-32? SLES11 should still be supported, 
> and that should have x86-32 version; any chance SUSE can share some 
> patches?

We are sharing sources of all our kernels at

http://kernel.suse.com/

If you can find the x86-32 support there, it's yours (hint: you won't).

Otherwise, you'd either have to wait until we (or someone else) implements 
it (it's on our list), or implement it yourself.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: Linux 4.15-rc7

[Jiri Kosina]

On Thu, 11 Jan 2018, Pavel Machek wrote:

> Is anyone working on KPTI for x86-32? SLES11 should still be supported, 
> and that should have x86-32 version; any chance SUSE can share some 
> patches?

We are sharing sources of all our kernels at

http://kernel.suse.com/

If you can find the x86-32 support there, it's yours (hint: you won't).

Otherwise, you'd either have to wait until we (or someone else) implements 
it (it's on our list), or implement it yourself.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: Linux 4.15-rc7

[Nikolay Borisov]

On 11.01.2018 13:29, Olivier Galibert wrote:
> Wasn't/Isn't the 4G/4G  memory layout for 32 bits essentially KPTI?

4g/4g was never accepted upstream

> 
>   OG.
> 
> 
> On Thu, Jan 11, 2018 at 12:32 AM, Pavel Machek  wrote:
>> Hi!
>>
>>> The one thing I want to do now that Meltdown and Spectre are public,
>>> is to give a *big* shout-out to the x86 people, and Thomas Gleixner in
>>> particular for really being on top of this.  It's been one huge
>>> annoyance, and honestly, Thomas really went over and beyond in this
>>> whole mess.  A lot of other people have obviously been involved too,
>>
>> As I understand it: KPTI prevents Meltdown attack on x86-64, but
>> Spectre means even x86-64 is not expected to be safe?
>>
>> Ok, so Meltdown is public... And I still have some nice 32-bit
>> machines I'd like to keep working.
>>
>> Proof of concept is out, https://github.com/IAIK/meltdown/ .
>>
>> Is anyone working on KPTI for x86-32? SLES11 should still be
>> supported, and that should have x86-32 version; any chance SUSE can
>> share some patches?
>>
>> Thanks,
>> Pavel
>> --
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) 
>> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Linux 4.15-rc7

[Nikolay Borisov]

On 11.01.2018 13:29, Olivier Galibert wrote:
> Wasn't/Isn't the 4G/4G  memory layout for 32 bits essentially KPTI?

4g/4g was never accepted upstream

> 
>   OG.
> 
> 
> On Thu, Jan 11, 2018 at 12:32 AM, Pavel Machek  wrote:
>> Hi!
>>
>>> The one thing I want to do now that Meltdown and Spectre are public,
>>> is to give a *big* shout-out to the x86 people, and Thomas Gleixner in
>>> particular for really being on top of this.  It's been one huge
>>> annoyance, and honestly, Thomas really went over and beyond in this
>>> whole mess.  A lot of other people have obviously been involved too,
>>
>> As I understand it: KPTI prevents Meltdown attack on x86-64, but
>> Spectre means even x86-64 is not expected to be safe?
>>
>> Ok, so Meltdown is public... And I still have some nice 32-bit
>> machines I'd like to keep working.
>>
>> Proof of concept is out, https://github.com/IAIK/meltdown/ .
>>
>> Is anyone working on KPTI for x86-32? SLES11 should still be
>> supported, and that should have x86-32 version; any chance SUSE can
>> share some patches?
>>
>> Thanks,
>> Pavel
>> --
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) 
>> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Linux 4.15-rc7

[Olivier Galibert]

Wasn't/Isn't the 4G/4G  memory layout for 32 bits essentially KPTI?

  OG.


On Thu, Jan 11, 2018 at 12:32 AM, Pavel Machek  wrote:
> Hi!
>
>> The one thing I want to do now that Meltdown and Spectre are public,
>> is to give a *big* shout-out to the x86 people, and Thomas Gleixner in
>> particular for really being on top of this.  It's been one huge
>> annoyance, and honestly, Thomas really went over and beyond in this
>> whole mess.  A lot of other people have obviously been involved too,
>
> As I understand it: KPTI prevents Meltdown attack on x86-64, but
> Spectre means even x86-64 is not expected to be safe?
>
> Ok, so Meltdown is public... And I still have some nice 32-bit
> machines I'd like to keep working.
>
> Proof of concept is out, https://github.com/IAIK/meltdown/ .
>
> Is anyone working on KPTI for x86-32? SLES11 should still be
> supported, and that should have x86-32 version; any chance SUSE can
> share some patches?
>
> Thanks,
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Linux 4.15-rc7

[Olivier Galibert]

Wasn't/Isn't the 4G/4G  memory layout for 32 bits essentially KPTI?

  OG.


On Thu, Jan 11, 2018 at 12:32 AM, Pavel Machek  wrote:
> Hi!
>
>> The one thing I want to do now that Meltdown and Spectre are public,
>> is to give a *big* shout-out to the x86 people, and Thomas Gleixner in
>> particular for really being on top of this.  It's been one huge
>> annoyance, and honestly, Thomas really went over and beyond in this
>> whole mess.  A lot of other people have obviously been involved too,
>
> As I understand it: KPTI prevents Meltdown attack on x86-64, but
> Spectre means even x86-64 is not expected to be safe?
>
> Ok, so Meltdown is public... And I still have some nice 32-bit
> machines I'd like to keep working.
>
> Proof of concept is out, https://github.com/IAIK/meltdown/ .
>
> Is anyone working on KPTI for x86-32? SLES11 should still be
> supported, and that should have x86-32 version; any chance SUSE can
> share some patches?
>
> Thanks,
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Linux 4.15-rc7

[Pavel Machek]

Hi!

> The one thing I want to do now that Meltdown and Spectre are public,
> is to give a *big* shout-out to the x86 people, and Thomas Gleixner in
> particular for really being on top of this.  It's been one huge
> annoyance, and honestly, Thomas really went over and beyond in this
> whole mess.  A lot of other people have obviously been involved too,

As I understand it: KPTI prevents Meltdown attack on x86-64, but
Spectre means even x86-64 is not expected to be safe?

Ok, so Meltdown is public... And I still have some nice 32-bit
machines I'd like to keep working.

Proof of concept is out, https://github.com/IAIK/meltdown/ .

Is anyone working on KPTI for x86-32? SLES11 should still be
supported, and that should have x86-32 version; any chance SUSE can
share some patches?

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Linux 4.15-rc7

[Pavel Machek]

Hi!

> The one thing I want to do now that Meltdown and Spectre are public,
> is to give a *big* shout-out to the x86 people, and Thomas Gleixner in
> particular for really being on top of this.  It's been one huge
> annoyance, and honestly, Thomas really went over and beyond in this
> whole mess.  A lot of other people have obviously been involved too,

As I understand it: KPTI prevents Meltdown attack on x86-64, but
Spectre means even x86-64 is not expected to be safe?

Ok, so Meltdown is public... And I still have some nice 32-bit
machines I'd like to keep working.

Proof of concept is out, https://github.com/IAIK/meltdown/ .

Is anyone working on KPTI for x86-32? SLES11 should still be
supported, and that should have x86-32 version; any chance SUSE can
share some patches?

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Linux 4.15-rc7

[Thomas Gleixner]

Linus,

On Sun, 7 Jan 2018, Linus Torvalds wrote:

> The one thing I want to do now that Meltdown and Spectre are public,
> is to give a *big* shout-out to the x86 people, and Thomas Gleixner in
> particular for really being on top of this.  It's been one huge
> annoyance, and honestly, Thomas really went over and beyond in this
> whole mess.  A lot of other people have obviously been involved too,
> don't get me wrong, but this is exactly the kind of issue that easily
> results in lots of nasty hacky patches because people are falling all
> over themselves trying to fix it and they can't even talk about why
> they are doing it in public, and Thomas  ended up being a huge
> reason for why it was all much easier for me to merge: because of the
> literally _months_ of work on quality control and gating these patches
> and making sure the end result was a clean and manageable series.
> 
> So a big *BIG* thanks to Thomas for making it so much easier for me to
> merge all this stuff.  The whole nasty TLB isolation patches would
> have been just _so_ much more horrible without him.

I'm deeply moved and feel a little ashamed as without the help of others
this wouldn't have been possible at all. So it's on me to hand over the
*BIG* thanks to:

  Ingo Molnar who was the git logistics mastermind behind this, the last
  sanity check before commit and the initial stress tester. Thanks
  especially for taking over most of the regular tip maintenance workload.

  Andi Lutomirksy for the great work on the entry code, cpu entry area, LDT
  mapping and the PCID rework and his reviews.

  Borislav Petkov for his meticulous reviews, his help with all AMD issues
  and being always on standby for testing and debugging despite his
  workload of backporting KAISER to dead kernels.

  Peter Zijlstra for his work on the tlb flush / PCID code, reviews and
  supporting me on the short trip into LDT VMA mapping which we had to drop
  for various reasons.

  Dave Hansen who did the initial KAISER port and helped all along with the
  rework in various ways

  Josh Poimboeuf for fixing up all the stacktrace issues we encountered

  Juergen Gross for helping out on the XEN side of things so we did
  not have to dig into the inwards of XEN/PV.

  Kess Cook for helping with coordination behind the scenes

  Greg Kroah-Hartman for not pestering us with all the pre 4.14 backports
  and the smooth integration and exposure to 4.14 stable which gave us more
  test coverage and helped us to iron out the inevitable hickups.

  Linus for keeping his diving harpune in the cabinet and giving us great
  support for getting this into his tree on time which allowed 4.14 to gain
  all the goods as well.

  The team at TU Graz who did the initial KAISER implementation. I'm really
  impressed what kernel first timers can achieve and I have to say that I
  see worse code in my daily work as a maintainer. Congrats to them for
  their findings in the guts of our CPUs as well. Really impressive!

This list is surely not complete, so I extend the thanks to everyone who
helped with review, patches, testing, bug reports and regression hunting.

I want to take the opportunity to say thanks to my wife Monika, my family
and my great team @linutronix for bearing with the extraordinary grumpy old
greybeard which I certainly was for the past two month.

It's been an interesting challenge to sort that out in such a short
timeframe, but I'm sure all of the involved people would have preferred to
do this with the head start which at least one other OS got on this.

But it's not time yet for a post-mortem of this mess, we still have to sort
out the spectre mitigations and it seems Linus expects me to keep my hand
on things for the next time. Aye, aye, captain!

Lets sort this in a technical manner, with the security of our users in
mind and then take a break and after that sit down and gain the performance
back which we lost on the way. Lots of work ahead.

Thanks,

Thomas

Re: Linux 4.15-rc7

[Thomas Gleixner]

Linus,

On Sun, 7 Jan 2018, Linus Torvalds wrote:

> The one thing I want to do now that Meltdown and Spectre are public,
> is to give a *big* shout-out to the x86 people, and Thomas Gleixner in
> particular for really being on top of this.  It's been one huge
> annoyance, and honestly, Thomas really went over and beyond in this
> whole mess.  A lot of other people have obviously been involved too,
> don't get me wrong, but this is exactly the kind of issue that easily
> results in lots of nasty hacky patches because people are falling all
> over themselves trying to fix it and they can't even talk about why
> they are doing it in public, and Thomas  ended up being a huge
> reason for why it was all much easier for me to merge: because of the
> literally _months_ of work on quality control and gating these patches
> and making sure the end result was a clean and manageable series.
> 
> So a big *BIG* thanks to Thomas for making it so much easier for me to
> merge all this stuff.  The whole nasty TLB isolation patches would
> have been just _so_ much more horrible without him.

I'm deeply moved and feel a little ashamed as without the help of others
this wouldn't have been possible at all. So it's on me to hand over the
*BIG* thanks to:

  Ingo Molnar who was the git logistics mastermind behind this, the last
  sanity check before commit and the initial stress tester. Thanks
  especially for taking over most of the regular tip maintenance workload.

  Andi Lutomirksy for the great work on the entry code, cpu entry area, LDT
  mapping and the PCID rework and his reviews.

  Borislav Petkov for his meticulous reviews, his help with all AMD issues
  and being always on standby for testing and debugging despite his
  workload of backporting KAISER to dead kernels.

  Peter Zijlstra for his work on the tlb flush / PCID code, reviews and
  supporting me on the short trip into LDT VMA mapping which we had to drop
  for various reasons.

  Dave Hansen who did the initial KAISER port and helped all along with the
  rework in various ways

  Josh Poimboeuf for fixing up all the stacktrace issues we encountered

  Juergen Gross for helping out on the XEN side of things so we did
  not have to dig into the inwards of XEN/PV.

  Kess Cook for helping with coordination behind the scenes

  Greg Kroah-Hartman for not pestering us with all the pre 4.14 backports
  and the smooth integration and exposure to 4.14 stable which gave us more
  test coverage and helped us to iron out the inevitable hickups.

  Linus for keeping his diving harpune in the cabinet and giving us great
  support for getting this into his tree on time which allowed 4.14 to gain
  all the goods as well.

  The team at TU Graz who did the initial KAISER implementation. I'm really
  impressed what kernel first timers can achieve and I have to say that I
  see worse code in my daily work as a maintainer. Congrats to them for
  their findings in the guts of our CPUs as well. Really impressive!

This list is surely not complete, so I extend the thanks to everyone who
helped with review, patches, testing, bug reports and regression hunting.

I want to take the opportunity to say thanks to my wife Monika, my family
and my great team @linutronix for bearing with the extraordinary grumpy old
greybeard which I certainly was for the past two month.

It's been an interesting challenge to sort that out in such a short
timeframe, but I'm sure all of the involved people would have preferred to
do this with the head start which at least one other OS got on this.

But it's not time yet for a post-mortem of this mess, we still have to sort
out the spectre mitigations and it seems Linus expects me to keep my hand
on things for the next time. Aye, aye, captain!

Lets sort this in a technical manner, with the security of our users in
mind and then take a break and after that sit down and gain the performance
back which we lost on the way. Lots of work ahead.

Thanks,

Thomas

Linux 4.15-rc7

[Linus Torvalds]

ster name mess up.

Dmitry Torokhov (1):
  Input: elants_i2c - do not clobber interrupt trigger on x86

Eric Biggers (3):
  crypto: chacha20poly1305 - validate the digest size
  crypto: pcrypt - fix freeing pcrypt instances
  capabilities: fix buffer overread on very short xattr

Eric W. Biederman (1):
  pid: Handle failure to allocate the first pid in a pid namespace

Eugeniy Paltsev (4):
  ARC: [plat-hsdk]: Set initial core pll output frequency
  ARC: [plat-hsdk]: Get rid of core pll frequency set in platform code
  ARC: [plat-axs103]: Set initial core pll output frequency
  ARC: [plat-axs103] refactor the quad core DT quirk code

Hans Verkuil (1):
  omapdrm/dss/hdmi4_cec: fix interrupt handling

Heiko Carstens (1):
  s390/sclp: disable FORTIFY_SOURCE for early sclp code

Heiko Stuebner (3):
  ARM: dts: rockchip: add cpu0-regulator on rk3066a-marsboard
  arm64: dts: rockchip: fix trailing 0 in rk3328 tsadc interrupts
  arm64: dts: rockchip: limit rk3328-rock64 gmac speed to 100MBit for now

Helge Deller (6):
  parisc: Show unhashed hardware inventory
  parisc: Show initial kernel memory layout unhashed
  parisc: Show unhashed HPA of Dino chip
  parisc: Show unhashed EISA EEPROM address
  parisc: Fix alignment of pa_tlb_lock in assembly on 32-bit SMP kernel
  parisc: qemu idle sleep support

Icenowy Zheng (1):
  arm64: allwinner: a64: add Ethernet PHY regulator for several boards

Jacek Anaszewski (1):
  leds: core: Fix regression caused by commit 2b83ff96f51d

Jagan Teki (1):
  arm64: allwinner: a64-sopine: Fix to use dcdc1 regulator instead of vcc3v3

James Hogan (1):
  lib/mpi: Fix umul_ppmm() for MIPS64r6

Jan Engelhardt (1):
  crypto: n2 - cure use after free

Javier Martinez Canillas (1):
  ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine

Jean-Philippe Brucker (1):
  iommu/arm-smmu-v3: Don't free page table ops twice

Jeffy Chen (1):
  mailmap: update Mark Yao's email address

Jim Mattson (1):
  kvm: vmx: Scrub hardware GPRs at VM-exit

Joel Stanley (1):
  ARM: dts: aspeed-g4: Correct VUART IRQ number

John Johansen (1):
  apparmor: fix regression in mount mediation when feature set is pinned

John Sperbeck (1):
  powerpc/mm: Fix SEGV on mapped region to return SEGV_ACCERR

Jonathan Cameron (1):
  crypto: af_alg - Fix race around ctx->rcvused by making it atomic_t

Josh Poimboeuf (2):
  x86/dumpstack: Fix partial register dumps
  x86/dumpstack: Print registers for first stack frame

Kees Cook (1):
  exec: Weaken dumpability for secureexec

Klaus Goger (1):
  arm64: dts: rockchip: remove vdd_log from rk3399-puma

Linus Torvalds (1):
  Linux 4.15-rc7

Lucas De Marchi (1):
  drm/i915: Apply Display WA #1183 on skl, kbl, and cfl

Markus Heiser (1):
  docs: fix, intel_guc_loader.c has been moved to intel_guc_fw.c

Martin Schwidefsky (1):
  s390: fix preemption race in disable_sacf_uaccess

Masahiro Yamada (1):
  arm64: dts: uniphier: fix gpio-ranges property of PXs3 SoC

Matt Fleming (1):
  MAINTAINERS: Remove Matt Fleming as EFI co-maintainer

Matthew Wilcox (1):
  mm/debug.c: provide useful debugging information for VM_BUG

Maxime Ripard (1):
  ARM: dts: sun8i: a711: Reinstate the PMIC compatible

Nick Desaulniers (1):
  x86/process: Define cpu_tss_rw in same section as declaration

Nikolay Borisov (1):
  btrfs: Fix flush bio leak

Ofer Heifetz (1):
  crypto: inside-secure - per request invalidation

Oleg Nesterov (1):
  kernel/acct.c: fix the acct->needcheck check in check_free_space()

Oleksandr Andrushchenko (1):
  Input: xen-kbdfront - do not advertise multi-touch pressure support

Olof Johansson (1):
  Input: joystick/analog - riscv has get_cycles()

Peter Rosin (1):
  ARM: dts: at91: disable the nxp,se97b SMBUS timeout on the TSE-850

Peter Zijlstra (1):
  x86/events/intel/ds: Use the proper cache flush method for
mapping ds buffers

Randy Dunlap (1):
  documentation/gpu/i915: fix docs build error after file rename

Rob Herring (1):
  ARM: dts: rockchip: fix rk3288 iep-IOMMU interrupts property cells

Robin Murphy (1):
  iommu/arm-smmu-v3: Cope with duplicated Stream IDs

Russell King (5):
  drm/armada: fix leak of crtc structure
  drm/armada: fix SRAM powerdown
  drm/armada: fix UV swap code
  drm/armada: improve efficiency of armada_drm_plane_calc_addrs()
  drm/armada: fix YUV planar format framebuffer offsets

Sebastian Ott (1):
  s390/pci: handle insufficient resources during dma tlb flush

Sergey Matyukevich (1):
  arm64: dts: orange-pi-zero-plus2: fix sdcard detect

Sergey Senozhatsky (2):
  arc: do not use __print_symbol()
  mm/zsmalloc.c: include fs.h

Sinan Kaya (1):
  mfd: rtsx: Release IRQ during shutdown

Stefan Brüns (1):
  sunxi-rsb: Include OF based modalias in device uevent

Stefan Haberland (

Linux 4.15-rc7

[Linus Torvalds]

ster name mess up.

Dmitry Torokhov (1):
  Input: elants_i2c - do not clobber interrupt trigger on x86

Eric Biggers (3):
  crypto: chacha20poly1305 - validate the digest size
  crypto: pcrypt - fix freeing pcrypt instances
  capabilities: fix buffer overread on very short xattr

Eric W. Biederman (1):
  pid: Handle failure to allocate the first pid in a pid namespace

Eugeniy Paltsev (4):
  ARC: [plat-hsdk]: Set initial core pll output frequency
  ARC: [plat-hsdk]: Get rid of core pll frequency set in platform code
  ARC: [plat-axs103]: Set initial core pll output frequency
  ARC: [plat-axs103] refactor the quad core DT quirk code

Hans Verkuil (1):
  omapdrm/dss/hdmi4_cec: fix interrupt handling

Heiko Carstens (1):
  s390/sclp: disable FORTIFY_SOURCE for early sclp code

Heiko Stuebner (3):
  ARM: dts: rockchip: add cpu0-regulator on rk3066a-marsboard
  arm64: dts: rockchip: fix trailing 0 in rk3328 tsadc interrupts
  arm64: dts: rockchip: limit rk3328-rock64 gmac speed to 100MBit for now

Helge Deller (6):
  parisc: Show unhashed hardware inventory
  parisc: Show initial kernel memory layout unhashed
  parisc: Show unhashed HPA of Dino chip
  parisc: Show unhashed EISA EEPROM address
  parisc: Fix alignment of pa_tlb_lock in assembly on 32-bit SMP kernel
  parisc: qemu idle sleep support

Icenowy Zheng (1):
  arm64: allwinner: a64: add Ethernet PHY regulator for several boards

Jacek Anaszewski (1):
  leds: core: Fix regression caused by commit 2b83ff96f51d

Jagan Teki (1):
  arm64: allwinner: a64-sopine: Fix to use dcdc1 regulator instead of vcc3v3

James Hogan (1):
  lib/mpi: Fix umul_ppmm() for MIPS64r6

Jan Engelhardt (1):
  crypto: n2 - cure use after free

Javier Martinez Canillas (1):
  ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine

Jean-Philippe Brucker (1):
  iommu/arm-smmu-v3: Don't free page table ops twice

Jeffy Chen (1):
  mailmap: update Mark Yao's email address

Jim Mattson (1):
  kvm: vmx: Scrub hardware GPRs at VM-exit

Joel Stanley (1):
  ARM: dts: aspeed-g4: Correct VUART IRQ number

John Johansen (1):
  apparmor: fix regression in mount mediation when feature set is pinned

John Sperbeck (1):
  powerpc/mm: Fix SEGV on mapped region to return SEGV_ACCERR

Jonathan Cameron (1):
  crypto: af_alg - Fix race around ctx->rcvused by making it atomic_t

Josh Poimboeuf (2):
  x86/dumpstack: Fix partial register dumps
  x86/dumpstack: Print registers for first stack frame

Kees Cook (1):
  exec: Weaken dumpability for secureexec

Klaus Goger (1):
  arm64: dts: rockchip: remove vdd_log from rk3399-puma

Linus Torvalds (1):
  Linux 4.15-rc7

Lucas De Marchi (1):
  drm/i915: Apply Display WA #1183 on skl, kbl, and cfl

Markus Heiser (1):
  docs: fix, intel_guc_loader.c has been moved to intel_guc_fw.c

Martin Schwidefsky (1):
  s390: fix preemption race in disable_sacf_uaccess

Masahiro Yamada (1):
  arm64: dts: uniphier: fix gpio-ranges property of PXs3 SoC

Matt Fleming (1):
  MAINTAINERS: Remove Matt Fleming as EFI co-maintainer

Matthew Wilcox (1):
  mm/debug.c: provide useful debugging information for VM_BUG

Maxime Ripard (1):
  ARM: dts: sun8i: a711: Reinstate the PMIC compatible

Nick Desaulniers (1):
  x86/process: Define cpu_tss_rw in same section as declaration

Nikolay Borisov (1):
  btrfs: Fix flush bio leak

Ofer Heifetz (1):
  crypto: inside-secure - per request invalidation

Oleg Nesterov (1):
  kernel/acct.c: fix the acct->needcheck check in check_free_space()

Oleksandr Andrushchenko (1):
  Input: xen-kbdfront - do not advertise multi-touch pressure support

Olof Johansson (1):
  Input: joystick/analog - riscv has get_cycles()

Peter Rosin (1):
  ARM: dts: at91: disable the nxp,se97b SMBUS timeout on the TSE-850

Peter Zijlstra (1):
  x86/events/intel/ds: Use the proper cache flush method for
mapping ds buffers

Randy Dunlap (1):
  documentation/gpu/i915: fix docs build error after file rename

Rob Herring (1):
  ARM: dts: rockchip: fix rk3288 iep-IOMMU interrupts property cells

Robin Murphy (1):
  iommu/arm-smmu-v3: Cope with duplicated Stream IDs

Russell King (5):
  drm/armada: fix leak of crtc structure
  drm/armada: fix SRAM powerdown
  drm/armada: fix UV swap code
  drm/armada: improve efficiency of armada_drm_plane_calc_addrs()
  drm/armada: fix YUV planar format framebuffer offsets

Sebastian Ott (1):
  s390/pci: handle insufficient resources during dma tlb flush

Sergey Matyukevich (1):
  arm64: dts: orange-pi-zero-plus2: fix sdcard detect

Sergey Senozhatsky (2):
  arc: do not use __print_symbol()
  mm/zsmalloc.c: include fs.h

Sinan Kaya (1):
  mfd: rtsx: Release IRQ during shutdown

Stefan Brüns (1):
  sunxi-rsb: Include OF based modalias in device uevent

Stefan Haberland (

[GIT PULL] KVM fixes for Linux 4.15-rc7

[Radim Krčmář]

Linus,

The following changes since commit aa12f594f97efe50223611dbd13ecca4e8dafee6:

  tools/kvm_stat: sort '-f help' output (2017-12-21 13:03:32 +0100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/virt/kvm/kvm for-linus

for you to fetch changes up to bb4945e60dd0b5afb0e92bc8006ce560948fbc39:

  Merge tag 'kvm-s390-master-4.15-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux (2018-01-06 
17:26:37 +0100)


KVM fixes for v4.15-rc7

s390:
* Two fixes for potential bitmap overruns in the cmma migration code

x86:
* Clear guest provided GPRs to defeat the Project Zero PoC for CVE
  2017-5715


Christian Borntraeger (2):
  KVM: s390: fix cmma migration for multiple memory slots
  KVM: s390: prevent buffer overrun on memory hotplug during migration

Jim Mattson (1):
  kvm: vmx: Scrub hardware GPRs at VM-exit

Radim Krčmář (1):
  Merge tag 'kvm-s390-master-4.15-2' of 
git://git.kernel.org/.../kvms390/linux

 arch/s390/kvm/kvm-s390.c |  9 +
 arch/s390/kvm/priv.c |  2 +-
 arch/x86/kvm/svm.c   | 19 +++
 arch/x86/kvm/vmx.c   | 14 +-
 4 files changed, 38 insertions(+), 6 deletions(-)

[GIT PULL] KVM fixes for Linux 4.15-rc7

[Radim Krčmář]

Linus,

The following changes since commit aa12f594f97efe50223611dbd13ecca4e8dafee6:

  tools/kvm_stat: sort '-f help' output (2017-12-21 13:03:32 +0100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/virt/kvm/kvm for-linus

for you to fetch changes up to bb4945e60dd0b5afb0e92bc8006ce560948fbc39:

  Merge tag 'kvm-s390-master-4.15-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux (2018-01-06 
17:26:37 +0100)


KVM fixes for v4.15-rc7

s390:
* Two fixes for potential bitmap overruns in the cmma migration code

x86:
* Clear guest provided GPRs to defeat the Project Zero PoC for CVE
  2017-5715


Christian Borntraeger (2):
  KVM: s390: fix cmma migration for multiple memory slots
  KVM: s390: prevent buffer overrun on memory hotplug during migration

Jim Mattson (1):
  kvm: vmx: Scrub hardware GPRs at VM-exit

Radim Krčmář (1):
  Merge tag 'kvm-s390-master-4.15-2' of 
git://git.kernel.org/.../kvms390/linux

 arch/s390/kvm/kvm-s390.c |  9 +
 arch/s390/kvm/priv.c |  2 +-
 arch/x86/kvm/svm.c   | 19 +++
 arch/x86/kvm/vmx.c   | 14 +-
 4 files changed, 38 insertions(+), 6 deletions(-)