Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Jon Masters]

On 01/07/2018 04:48 PM, Thomas Gleixner wrote:

> +#ifdef CONFIG_GENERIC_CPU_VULNERABILITIES
> +
> +ssize_t __weak cpu_show_meltdown(struct device *dev,
> +  struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "Not affected\n");
> +}
> +
> +ssize_t __weak cpu_show_spectre_v1(struct device *dev,
> +struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "Not affected\n");
> +}
> +
> +ssize_t __weak cpu_show_spectre_v2(struct device *dev,
> +struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "Not affected\n");
> +}

Just wondering aloud (after the merge) here but shouldn't the default be
"unknown", at least for Spectre? It's pervasive enough.

Jon.

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Jon Masters]

On 01/07/2018 04:48 PM, Thomas Gleixner wrote:

> +#ifdef CONFIG_GENERIC_CPU_VULNERABILITIES
> +
> +ssize_t __weak cpu_show_meltdown(struct device *dev,
> +  struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "Not affected\n");
> +}
> +
> +ssize_t __weak cpu_show_spectre_v1(struct device *dev,
> +struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "Not affected\n");
> +}
> +
> +ssize_t __weak cpu_show_spectre_v2(struct device *dev,
> +struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "Not affected\n");
> +}

Just wondering aloud (after the merge) here but shouldn't the default be
"unknown", at least for Spectre? It's pervasive enough.

Jon.

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Greg Kroah-Hartman]

On Fri, Jan 26, 2018 at 05:23:31PM +0100, Andrea Arcangeli wrote:
> Hello,
> 
> On Sun, Jan 07, 2018 at 10:48:00PM +0100, Thomas Gleixner wrote:
> > +static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL);
> > +static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL);
> > +static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL);
> 
> This sysfs feature implemented as above is weakening kernel security,
> it should be 0400 above.

See the patch from Jason A. Donenfeld  to do just that:
Subject: [PATCH] cpu: do not leak vulnerabilities to unprivileged users
Message-Id: <20180125120401.30596-1-ja...@zx2c4.com>

I'll be queueing it up for 4.16-rc1 and backport it everywhere.

thanks,

greg k-h

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Greg Kroah-Hartman]

On Fri, Jan 26, 2018 at 05:23:31PM +0100, Andrea Arcangeli wrote:
> Hello,
> 
> On Sun, Jan 07, 2018 at 10:48:00PM +0100, Thomas Gleixner wrote:
> > +static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL);
> > +static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL);
> > +static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL);
> 
> This sysfs feature implemented as above is weakening kernel security,
> it should be 0400 above.

See the patch from Jason A. Donenfeld  to do just that:
Subject: [PATCH] cpu: do not leak vulnerabilities to unprivileged users
Message-Id: <20180125120401.30596-1-ja...@zx2c4.com>

I'll be queueing it up for 4.16-rc1 and backport it everywhere.

thanks,

greg k-h

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Andrea Arcangeli]

Hello,

On Sun, Jan 07, 2018 at 10:48:00PM +0100, Thomas Gleixner wrote:
> +static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL);
> +static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL);
> +static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL);

This sysfs feature implemented as above is weakening kernel security,
it should be 0400 above.

It doesn't make sense to expose to luser when a software fix (or even
only a software mitigation) has been disabled at build time to gain
all performance back (see CONFIG_RETPOLINE=n config option).

$ cat /boot/kernel-`uname -r`
cat: /boot/kernel-4.15.0-rc9+: Permission denied
$ cat /lib/modules/`uname -r`/kernel/arch/x86/kvm/kvm.ko 
cat: /lib/modules/4.15.0-rc9+/kernel/arch/x86/kvm/kvm.ko: Permission denied
$ dmesg
dmesg: read kernel buffer failed: Operation not permitted

Noticing when cr3 is flipped in kernel/exit is easy, but noticing when
the syscall table or the whole kernel has been built with retpolines
is not trivial to detect. Same for variant#1.

Exploiting spectre variant#2 for an attacker is not without risk of
being detected while the setup is being mounted, as the CPU load would
spike for hours.

I may notice if a random background network daemon suddenly starts
running at 100% CPU load for hours (especially on mobile devices that
would be physically noticeable).

Containers shouldn't have sysfs and you can workaround the above if
you run all network daemons behind mount namespaces, but in general
leaving this directory readable by luser is weaking security because
it exposes when mounting a variant#2 attack can succeed.

It even tells when it is worth to focus on the syscall_table indirect
call or if the attack needs to dig deeper because asm retpolines were
used, but the kernel was built with a gcc without retpolines.

The only case where the above isn't weakening security is when the
full fix is on for all the variants is enabled (and variant#1 for now
just shows vulnerable..).

For the same reasons the whole directory, not just the files, should be
0500, especially if this would be used for any other equivalent issue
in the future and it won't stick to these 3 files, I didn't implement
that yet, because it's less urgent if nobody adds any more files soon.

>From 578b411c8dcb1435dd1f94a6cd062f4eedb70fb5 Mon Sep 17 00:00:00 2001
From: Andrea Arcangeli 
Date: Wed, 24 Jan 2018 19:19:36 +0100
Subject: [PATCH 1/1] x86/spectre/meltdown: avoid the vulnerability directory
 to weaken kernel security

If any of the fixes is disabled to gain some performance back at
runtime or build time, should not be exposed to unprivileged userland.

Signed-off-by: Andrea Arcangeli 
---
 drivers/base/cpu.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index d99038487a0d..a3a8e008f957 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -531,9 +531,9 @@ ssize_t __weak cpu_show_spectre_v2(struct device *dev,
return sprintf(buf, "Not affected\n");
 }
 
-static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL);
-static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL);
-static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL);
+static DEVICE_ATTR(meltdown, 0400, cpu_show_meltdown, NULL);
+static DEVICE_ATTR(spectre_v1, 0400, cpu_show_spectre_v1, NULL);
+static DEVICE_ATTR(spectre_v2, 0400, cpu_show_spectre_v2, NULL);
 
 static struct attribute *cpu_root_vulnerabilities_attrs[] = {
_attr_meltdown.attr,

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Andrea Arcangeli]

Hello,

On Sun, Jan 07, 2018 at 10:48:00PM +0100, Thomas Gleixner wrote:
> +static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL);
> +static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL);
> +static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL);

This sysfs feature implemented as above is weakening kernel security,
it should be 0400 above.

It doesn't make sense to expose to luser when a software fix (or even
only a software mitigation) has been disabled at build time to gain
all performance back (see CONFIG_RETPOLINE=n config option).

$ cat /boot/kernel-`uname -r`
cat: /boot/kernel-4.15.0-rc9+: Permission denied
$ cat /lib/modules/`uname -r`/kernel/arch/x86/kvm/kvm.ko 
cat: /lib/modules/4.15.0-rc9+/kernel/arch/x86/kvm/kvm.ko: Permission denied
$ dmesg
dmesg: read kernel buffer failed: Operation not permitted

Noticing when cr3 is flipped in kernel/exit is easy, but noticing when
the syscall table or the whole kernel has been built with retpolines
is not trivial to detect. Same for variant#1.

Exploiting spectre variant#2 for an attacker is not without risk of
being detected while the setup is being mounted, as the CPU load would
spike for hours.

I may notice if a random background network daemon suddenly starts
running at 100% CPU load for hours (especially on mobile devices that
would be physically noticeable).

Containers shouldn't have sysfs and you can workaround the above if
you run all network daemons behind mount namespaces, but in general
leaving this directory readable by luser is weaking security because
it exposes when mounting a variant#2 attack can succeed.

It even tells when it is worth to focus on the syscall_table indirect
call or if the attack needs to dig deeper because asm retpolines were
used, but the kernel was built with a gcc without retpolines.

The only case where the above isn't weakening security is when the
full fix is on for all the variants is enabled (and variant#1 for now
just shows vulnerable..).

For the same reasons the whole directory, not just the files, should be
0500, especially if this would be used for any other equivalent issue
in the future and it won't stick to these 3 files, I didn't implement
that yet, because it's less urgent if nobody adds any more files soon.

>From 578b411c8dcb1435dd1f94a6cd062f4eedb70fb5 Mon Sep 17 00:00:00 2001
From: Andrea Arcangeli 
Date: Wed, 24 Jan 2018 19:19:36 +0100
Subject: [PATCH 1/1] x86/spectre/meltdown: avoid the vulnerability directory
 to weaken kernel security

If any of the fixes is disabled to gain some performance back at
runtime or build time, should not be exposed to unprivileged userland.

Signed-off-by: Andrea Arcangeli 
---
 drivers/base/cpu.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index d99038487a0d..a3a8e008f957 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -531,9 +531,9 @@ ssize_t __weak cpu_show_spectre_v2(struct device *dev,
return sprintf(buf, "Not affected\n");
 }
 
-static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL);
-static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL);
-static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL);
+static DEVICE_ATTR(meltdown, 0400, cpu_show_meltdown, NULL);
+static DEVICE_ATTR(spectre_v1, 0400, cpu_show_spectre_v1, NULL);
+static DEVICE_ATTR(spectre_v2, 0400, cpu_show_spectre_v2, NULL);
 
 static struct attribute *cpu_root_vulnerabilities_attrs[] = {
_attr_meltdown.attr,

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Alexey Dobriyan]

On Mon, Jan 08, 2018 at 11:54:54AM +, Alan Cox wrote:
> On Mon, 8 Jan 2018 08:35:14 +0300
> Alexey Dobriyan  wrote:
> 
> > On Sun, Jan 07, 2018 at 10:50:58PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Jan 08, 2018 at 01:22:04AM +0300, Alexey Dobriyan wrote:  
> > > > Thomas Gleixner wrote:  
> > > > > Create /sys/devices/system/cpu/vulnerabilities folder and files for
> > > > > meltdown, spectre_v1 and spectre_v2.  
> > > > 
> > > > It is called "grep -e '^bugs' /proc/cpuinfo".
> > > > 
> > > > kpti is deduceable from .config and /proc/cmdline .
> > > > If people don't know what .config they are running, god bless them.  
> > > 
> > > It is not just for meltdown (kpti). You also have retpoline and IBRS
> > > which is for spectre.  
> > 
> > If you, as kernel developer, are sure that bug is properly mitigated
> > to the best of your knowledge then clear the bit from the bug mask.
> 
> It's probably useful to have the mitigation status somewhere because that
> is what most people will care about. Both pieces of information are
> needed though.

Then proper way for mainline is Documentation/.

Kernel doesn't announce many things such as ASLR, it simply enables it
by default.

Real checks are done by disassembly and verifying that generated
code does what's necessary anyway. But dumbed down version doesn't need
runtime file in sysfs, internet page somewhere (kernel.org gitweb
interface) should be enough.

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Alexey Dobriyan]

On Mon, Jan 08, 2018 at 11:54:54AM +, Alan Cox wrote:
> On Mon, 8 Jan 2018 08:35:14 +0300
> Alexey Dobriyan  wrote:
> 
> > On Sun, Jan 07, 2018 at 10:50:58PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Jan 08, 2018 at 01:22:04AM +0300, Alexey Dobriyan wrote:  
> > > > Thomas Gleixner wrote:  
> > > > > Create /sys/devices/system/cpu/vulnerabilities folder and files for
> > > > > meltdown, spectre_v1 and spectre_v2.  
> > > > 
> > > > It is called "grep -e '^bugs' /proc/cpuinfo".
> > > > 
> > > > kpti is deduceable from .config and /proc/cmdline .
> > > > If people don't know what .config they are running, god bless them.  
> > > 
> > > It is not just for meltdown (kpti). You also have retpoline and IBRS
> > > which is for spectre.  
> > 
> > If you, as kernel developer, are sure that bug is properly mitigated
> > to the best of your knowledge then clear the bit from the bug mask.
> 
> It's probably useful to have the mitigation status somewhere because that
> is what most people will care about. Both pieces of information are
> needed though.

Then proper way for mainline is Documentation/.

Kernel doesn't announce many things such as ASLR, it simply enables it
by default.

Real checks are done by disassembly and verifying that generated
code does what's necessary anyway. But dumbed down version doesn't need
runtime file in sysfs, internet page somewhere (kernel.org gitweb
interface) should be enough.

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Alan Cox]

On Mon, 8 Jan 2018 08:35:14 +0300
Alexey Dobriyan  wrote:

> On Sun, Jan 07, 2018 at 10:50:58PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jan 08, 2018 at 01:22:04AM +0300, Alexey Dobriyan wrote:  
> > > Thomas Gleixner wrote:  
> > > > Create /sys/devices/system/cpu/vulnerabilities folder and files for
> > > > meltdown, spectre_v1 and spectre_v2.  
> > > 
> > > It is called "grep -e '^bugs' /proc/cpuinfo".
> > > 
> > > kpti is deduceable from .config and /proc/cmdline .
> > > If people don't know what .config they are running, god bless them.  
> > 
> > It is not just for meltdown (kpti). You also have retpoline and IBRS
> > which is for spectre.  
> 
> If you, as kernel developer, are sure that bug is properly mitigated
> to the best of your knowledge then clear the bit from the bug mask.

It's probably useful to have the mitigation status somewhere because that
is what most people will care about. Both pieces of information are
needed though.

Alan

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Alan Cox]

On Mon, 8 Jan 2018 08:35:14 +0300
Alexey Dobriyan  wrote:

> On Sun, Jan 07, 2018 at 10:50:58PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jan 08, 2018 at 01:22:04AM +0300, Alexey Dobriyan wrote:  
> > > Thomas Gleixner wrote:  
> > > > Create /sys/devices/system/cpu/vulnerabilities folder and files for
> > > > meltdown, spectre_v1 and spectre_v2.  
> > > 
> > > It is called "grep -e '^bugs' /proc/cpuinfo".
> > > 
> > > kpti is deduceable from .config and /proc/cmdline .
> > > If people don't know what .config they are running, god bless them.  
> > 
> > It is not just for meltdown (kpti). You also have retpoline and IBRS
> > which is for spectre.  
> 
> If you, as kernel developer, are sure that bug is properly mitigated
> to the best of your knowledge then clear the bit from the bug mask.

It's probably useful to have the mitigation status somewhere because that
is what most people will care about. Both pieces of information are
needed though.

Alan

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Alexey Dobriyan]

On 1/8/18, Thomas Gleixner  wrote:
> On Mon, 8 Jan 2018, Alexey Dobriyan wrote:
>> On Sun, Jan 07, 2018 at 10:50:58PM -0500, Konrad Rzeszutek Wilk wrote:
>> > On Mon, Jan 08, 2018 at 01:22:04AM +0300, Alexey Dobriyan wrote:
>> > > Thomas Gleixner wrote:
>> > > > Create /sys/devices/system/cpu/vulnerabilities folder and files for
>> > > > meltdown, spectre_v1 and spectre_v2.
>> > >
>> > > It is called "grep -e '^bugs' /proc/cpuinfo".
>> > >
>> > > kpti is deduceable from .config and /proc/cmdline .
>> > > If people don't know what .config they are running, god bless them.
>> >
>> > It is not just for meltdown (kpti). You also have retpoline and IBRS
>> > which is for spectre.
>>
>> If you, as kernel developer, are sure that bug is properly mitigated
>> to the best of your knowledge then clear the bit from the bug mask.
>
> Nope. The CPU is still buggy and does not become less so because we set a
> mitigation into effect.

There no reason why these files should exist, both technical and non-technical.

1) /proc/cpuinfo bugs section is time honored, this is where F00F and
FDIV lived.

2) marketing monikers are used, they are for hype, leave them to journalists.
I read both papers and bugs are cool but I have no clue which name is
which bug (and which variant!) because they are very meaningless
by themselves.

3) You're placing kernel on the hook for explaining users who is vulnerable.
But kernel is not vulnerable! CPU vendors should put a page and
distros refer to those pages. Then it is business as usual: write an advisory,
give instructions how to enable KPTI, give instructions how to get
new microcode and verify by checking for new flags in /proc/cpuinfo,
give instructions for using new compiler flags.

4) defaults
default is "Not affected" which is easily incorrect as nobody knows
what CPU manufacturers are doing.

Might as well say "Contact your CPU vendor for more information".
At this point file becomes meaningless.

5) it is not clear what the fuss is all about
There is no file which lists every mitigation (LIST_POISON, refcounting,
SLAB randomization, ASLR/KASLR etc), there is no reason to start now.


This is becoming WSJ-driven development (in wide sense of the word).

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Alexey Dobriyan]

On 1/8/18, Thomas Gleixner  wrote:
> On Mon, 8 Jan 2018, Alexey Dobriyan wrote:
>> On Sun, Jan 07, 2018 at 10:50:58PM -0500, Konrad Rzeszutek Wilk wrote:
>> > On Mon, Jan 08, 2018 at 01:22:04AM +0300, Alexey Dobriyan wrote:
>> > > Thomas Gleixner wrote:
>> > > > Create /sys/devices/system/cpu/vulnerabilities folder and files for
>> > > > meltdown, spectre_v1 and spectre_v2.
>> > >
>> > > It is called "grep -e '^bugs' /proc/cpuinfo".
>> > >
>> > > kpti is deduceable from .config and /proc/cmdline .
>> > > If people don't know what .config they are running, god bless them.
>> >
>> > It is not just for meltdown (kpti). You also have retpoline and IBRS
>> > which is for spectre.
>>
>> If you, as kernel developer, are sure that bug is properly mitigated
>> to the best of your knowledge then clear the bit from the bug mask.
>
> Nope. The CPU is still buggy and does not become less so because we set a
> mitigation into effect.

There no reason why these files should exist, both technical and non-technical.

1) /proc/cpuinfo bugs section is time honored, this is where F00F and
FDIV lived.

2) marketing monikers are used, they are for hype, leave them to journalists.
I read both papers and bugs are cool but I have no clue which name is
which bug (and which variant!) because they are very meaningless
by themselves.

3) You're placing kernel on the hook for explaining users who is vulnerable.
But kernel is not vulnerable! CPU vendors should put a page and
distros refer to those pages. Then it is business as usual: write an advisory,
give instructions how to enable KPTI, give instructions how to get
new microcode and verify by checking for new flags in /proc/cpuinfo,
give instructions for using new compiler flags.

4) defaults
default is "Not affected" which is easily incorrect as nobody knows
what CPU manufacturers are doing.

Might as well say "Contact your CPU vendor for more information".
At this point file becomes meaningless.

5) it is not clear what the fuss is all about
There is no file which lists every mitigation (LIST_POISON, refcounting,
SLAB randomization, ASLR/KASLR etc), there is no reason to start now.


This is becoming WSJ-driven development (in wide sense of the word).

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Thomas Gleixner]

On Mon, 8 Jan 2018, Alexey Dobriyan wrote:
> On Sun, Jan 07, 2018 at 10:50:58PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jan 08, 2018 at 01:22:04AM +0300, Alexey Dobriyan wrote:
> > > Thomas Gleixner wrote:
> > > > Create /sys/devices/system/cpu/vulnerabilities folder and files for
> > > > meltdown, spectre_v1 and spectre_v2.
> > > 
> > > It is called "grep -e '^bugs' /proc/cpuinfo".
> > > 
> > > kpti is deduceable from .config and /proc/cmdline .
> > > If people don't know what .config they are running, god bless them.
> > 
> > It is not just for meltdown (kpti). You also have retpoline and IBRS
> > which is for spectre.
> 
> If you, as kernel developer, are sure that bug is properly mitigated
> to the best of your knowledge then clear the bit from the bug mask.

Nope. The CPU is still buggy and does not become less so because we set a
mitigation into effect.

Thanks,

tglx

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Thomas Gleixner]

On Mon, 8 Jan 2018, Alexey Dobriyan wrote:
> On Sun, Jan 07, 2018 at 10:50:58PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jan 08, 2018 at 01:22:04AM +0300, Alexey Dobriyan wrote:
> > > Thomas Gleixner wrote:
> > > > Create /sys/devices/system/cpu/vulnerabilities folder and files for
> > > > meltdown, spectre_v1 and spectre_v2.
> > > 
> > > It is called "grep -e '^bugs' /proc/cpuinfo".
> > > 
> > > kpti is deduceable from .config and /proc/cmdline .
> > > If people don't know what .config they are running, god bless them.
> > 
> > It is not just for meltdown (kpti). You also have retpoline and IBRS
> > which is for spectre.
> 
> If you, as kernel developer, are sure that bug is properly mitigated
> to the best of your knowledge then clear the bit from the bug mask.

Nope. The CPU is still buggy and does not become less so because we set a
mitigation into effect.

Thanks,

tglx

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Thomas Gleixner]

On Mon, 8 Jan 2018, Dominik Brodowski wrote:
> On Sun, Jan 07, 2018 at 10:48:00PM +0100, Thomas Gleixner wrote:
> > As the meltdown/spectre problem affects several CPU architectures, it makes
> > sense to have common way to express whether a system is affected by a
> > particular vulnerability or not. If affected the way to express the
> > mitigation should be common as well.
> > 
> > Create /sys/devices/system/cpu/vulnerabilities folder and files for
> > meltdown, spectre_v1 and spectre_v2.
> > 
> > Allow architectures to override the show function.
> > 
> > Signed-off-by: Thomas Gleixner 
> > ---
> >  Documentation/ABI/testing/sysfs-devices-system-cpu |   16 +++
> >  drivers/base/Kconfig   |3 +
> >  drivers/base/cpu.c |   48 
> > +
> >  include/linux/cpu.h|7 +++
> >  4 files changed, 74 insertions(+)
> > 
> > --- a/Documentation/ABI/testing/sysfs-devices-system-cpu
> > +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
> > @@ -373,3 +373,19 @@ Contact:   Linux kernel mailing list  >  Description:   information about CPUs heterogeneity.
> >  
> > cpu_capacity: capacity of cpu#.
> > +
> > +What:  /sys/devices/system/cpu/vulnerabilities
> > +   /sys/devices/system/cpu/vulnerabilities/meltdown
> > +   /sys/devices/system/cpu/vulnerabilities/spectre_v1
> > +   /sys/devices/system/cpu/vulnerabilities/spectre_v2
> > +Date:  Januar 2018
> > +Contact:   Linux kernel mailing list 
> > +Description:   Information about CPU vulnerabilities
> > +
> > +   The files are named after the code names of CPU
> > +   vulnerabilities. The output of those files reflects the
> > +   state of the CPUs in the system.
> 
> Currently, your code sets X86_BUG_SPECTRE_V[12] unconditionally on x86
> CPUs. However, to my understanding some CPUs which do not execute code
> out-of-order aren't affected. As it is better to err on the safe side for
> now, what about adding a disclaimer at the end of this sentence, such as:
> 
>   ", but may contain false positives"

We do that in the same way as we did with BUG_INSECURE (now MELTDOWN). Err
out on the safe side and get the exceptions in place when people are
confident about them. It's not going to take long I assume.

Thanks,

tglx

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Thomas Gleixner]

On Mon, 8 Jan 2018, Dominik Brodowski wrote:
> On Sun, Jan 07, 2018 at 10:48:00PM +0100, Thomas Gleixner wrote:
> > As the meltdown/spectre problem affects several CPU architectures, it makes
> > sense to have common way to express whether a system is affected by a
> > particular vulnerability or not. If affected the way to express the
> > mitigation should be common as well.
> > 
> > Create /sys/devices/system/cpu/vulnerabilities folder and files for
> > meltdown, spectre_v1 and spectre_v2.
> > 
> > Allow architectures to override the show function.
> > 
> > Signed-off-by: Thomas Gleixner 
> > ---
> >  Documentation/ABI/testing/sysfs-devices-system-cpu |   16 +++
> >  drivers/base/Kconfig   |3 +
> >  drivers/base/cpu.c |   48 
> > +
> >  include/linux/cpu.h|7 +++
> >  4 files changed, 74 insertions(+)
> > 
> > --- a/Documentation/ABI/testing/sysfs-devices-system-cpu
> > +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
> > @@ -373,3 +373,19 @@ Contact:   Linux kernel mailing list  >  Description:   information about CPUs heterogeneity.
> >  
> > cpu_capacity: capacity of cpu#.
> > +
> > +What:  /sys/devices/system/cpu/vulnerabilities
> > +   /sys/devices/system/cpu/vulnerabilities/meltdown
> > +   /sys/devices/system/cpu/vulnerabilities/spectre_v1
> > +   /sys/devices/system/cpu/vulnerabilities/spectre_v2
> > +Date:  Januar 2018
> > +Contact:   Linux kernel mailing list 
> > +Description:   Information about CPU vulnerabilities
> > +
> > +   The files are named after the code names of CPU
> > +   vulnerabilities. The output of those files reflects the
> > +   state of the CPUs in the system.
> 
> Currently, your code sets X86_BUG_SPECTRE_V[12] unconditionally on x86
> CPUs. However, to my understanding some CPUs which do not execute code
> out-of-order aren't affected. As it is better to err on the safe side for
> now, what about adding a disclaimer at the end of this sentence, such as:
> 
>   ", but may contain false positives"

We do that in the same way as we did with BUG_INSECURE (now MELTDOWN). Err
out on the safe side and get the exceptions in place when people are
confident about them. It's not going to take long I assume.

Thanks,

tglx

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Dominik Brodowski]

On Sun, Jan 07, 2018 at 10:48:00PM +0100, Thomas Gleixner wrote:
> As the meltdown/spectre problem affects several CPU architectures, it makes
> sense to have common way to express whether a system is affected by a
> particular vulnerability or not. If affected the way to express the
> mitigation should be common as well.
> 
> Create /sys/devices/system/cpu/vulnerabilities folder and files for
> meltdown, spectre_v1 and spectre_v2.
> 
> Allow architectures to override the show function.
> 
> Signed-off-by: Thomas Gleixner 
> ---
>  Documentation/ABI/testing/sysfs-devices-system-cpu |   16 +++
>  drivers/base/Kconfig   |3 +
>  drivers/base/cpu.c |   48 
> +
>  include/linux/cpu.h|7 +++
>  4 files changed, 74 insertions(+)
> 
> --- a/Documentation/ABI/testing/sysfs-devices-system-cpu
> +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
> @@ -373,3 +373,19 @@ Contact: Linux kernel mailing list   Description: information about CPUs heterogeneity.
>  
>   cpu_capacity: capacity of cpu#.
> +
> +What:/sys/devices/system/cpu/vulnerabilities
> + /sys/devices/system/cpu/vulnerabilities/meltdown
> + /sys/devices/system/cpu/vulnerabilities/spectre_v1
> + /sys/devices/system/cpu/vulnerabilities/spectre_v2
> +Date:Januar 2018
> +Contact: Linux kernel mailing list 
> +Description: Information about CPU vulnerabilities
> +
> + The files are named after the code names of CPU
> + vulnerabilities. The output of those files reflects the
> + state of the CPUs in the system.

Currently, your code sets X86_BUG_SPECTRE_V[12] unconditionally on x86
CPUs. However, to my understanding some CPUs which do not execute code
out-of-order aren't affected. As it is better to err on the safe side for
now, what about adding a disclaimer at the end of this sentence, such as:

", but may contain false positives"

Thanks,
Dominik

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Dominik Brodowski]

On Sun, Jan 07, 2018 at 10:48:00PM +0100, Thomas Gleixner wrote:
> As the meltdown/spectre problem affects several CPU architectures, it makes
> sense to have common way to express whether a system is affected by a
> particular vulnerability or not. If affected the way to express the
> mitigation should be common as well.
> 
> Create /sys/devices/system/cpu/vulnerabilities folder and files for
> meltdown, spectre_v1 and spectre_v2.
> 
> Allow architectures to override the show function.
> 
> Signed-off-by: Thomas Gleixner 
> ---
>  Documentation/ABI/testing/sysfs-devices-system-cpu |   16 +++
>  drivers/base/Kconfig   |3 +
>  drivers/base/cpu.c |   48 
> +
>  include/linux/cpu.h|7 +++
>  4 files changed, 74 insertions(+)
> 
> --- a/Documentation/ABI/testing/sysfs-devices-system-cpu
> +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
> @@ -373,3 +373,19 @@ Contact: Linux kernel mailing list   Description: information about CPUs heterogeneity.
>  
>   cpu_capacity: capacity of cpu#.
> +
> +What:/sys/devices/system/cpu/vulnerabilities
> + /sys/devices/system/cpu/vulnerabilities/meltdown
> + /sys/devices/system/cpu/vulnerabilities/spectre_v1
> + /sys/devices/system/cpu/vulnerabilities/spectre_v2
> +Date:Januar 2018
> +Contact: Linux kernel mailing list 
> +Description: Information about CPU vulnerabilities
> +
> + The files are named after the code names of CPU
> + vulnerabilities. The output of those files reflects the
> + state of the CPUs in the system.

Currently, your code sets X86_BUG_SPECTRE_V[12] unconditionally on x86
CPUs. However, to my understanding some CPUs which do not execute code
out-of-order aren't affected. As it is better to err on the safe side for
now, what about adding a disclaimer at the end of this sentence, such as:

", but may contain false positives"

Thanks,
Dominik

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Greg Kroah-Hartman]

On Sun, Jan 07, 2018 at 10:48:00PM +0100, Thomas Gleixner wrote:
> As the meltdown/spectre problem affects several CPU architectures, it makes
> sense to have common way to express whether a system is affected by a
> particular vulnerability or not. If affected the way to express the
> mitigation should be common as well.
> 
> Create /sys/devices/system/cpu/vulnerabilities folder and files for
> meltdown, spectre_v1 and spectre_v2.
> 
> Allow architectures to override the show function.
> 
> Signed-off-by: Thomas Gleixner 

Thanks for the documentation update, looks good to me:

Reviewed-by: Greg Kroah-Hartman 

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Greg Kroah-Hartman]

On Sun, Jan 07, 2018 at 10:48:00PM +0100, Thomas Gleixner wrote:
> As the meltdown/spectre problem affects several CPU architectures, it makes
> sense to have common way to express whether a system is affected by a
> particular vulnerability or not. If affected the way to express the
> mitigation should be common as well.
> 
> Create /sys/devices/system/cpu/vulnerabilities folder and files for
> meltdown, spectre_v1 and spectre_v2.
> 
> Allow architectures to override the show function.
> 
> Signed-off-by: Thomas Gleixner 

Thanks for the documentation update, looks good to me:

Reviewed-by: Greg Kroah-Hartman 

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Alexey Dobriyan]

On Sun, Jan 07, 2018 at 10:50:58PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 08, 2018 at 01:22:04AM +0300, Alexey Dobriyan wrote:
> > Thomas Gleixner wrote:
> > > Create /sys/devices/system/cpu/vulnerabilities folder and files for
> > > meltdown, spectre_v1 and spectre_v2.
> > 
> > It is called "grep -e '^bugs' /proc/cpuinfo".
> > 
> > kpti is deduceable from .config and /proc/cmdline .
> > If people don't know what .config they are running, god bless them.
> 
> It is not just for meltdown (kpti). You also have retpoline and IBRS
> which is for spectre.

If you, as kernel developer, are sure that bug is properly mitigated
to the best of your knowledge then clear the bit from the bug mask.

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Alexey Dobriyan]

On Sun, Jan 07, 2018 at 10:50:58PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 08, 2018 at 01:22:04AM +0300, Alexey Dobriyan wrote:
> > Thomas Gleixner wrote:
> > > Create /sys/devices/system/cpu/vulnerabilities folder and files for
> > > meltdown, spectre_v1 and spectre_v2.
> > 
> > It is called "grep -e '^bugs' /proc/cpuinfo".
> > 
> > kpti is deduceable from .config and /proc/cmdline .
> > If people don't know what .config they are running, god bless them.
> 
> It is not just for meltdown (kpti). You also have retpoline and IBRS
> which is for spectre.

If you, as kernel developer, are sure that bug is properly mitigated
to the best of your knowledge then clear the bit from the bug mask.

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Konrad Rzeszutek Wilk]

On Mon, Jan 08, 2018 at 01:22:04AM +0300, Alexey Dobriyan wrote:
> Thomas Gleixner wrote:
> > Create /sys/devices/system/cpu/vulnerabilities folder and files for
> > meltdown, spectre_v1 and spectre_v2.
> 
> It is called "grep -e '^bugs' /proc/cpuinfo".
> 
> kpti is deduceable from .config and /proc/cmdline .
> If people don't know what .config they are running, god bless them.

It is not just for meltdown (kpti). You also have retpoline and IBRS
which is for spectre.

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Konrad Rzeszutek Wilk]

On Mon, Jan 08, 2018 at 01:22:04AM +0300, Alexey Dobriyan wrote:
> Thomas Gleixner wrote:
> > Create /sys/devices/system/cpu/vulnerabilities folder and files for
> > meltdown, spectre_v1 and spectre_v2.
> 
> It is called "grep -e '^bugs' /proc/cpuinfo".
> 
> kpti is deduceable from .config and /proc/cmdline .
> If people don't know what .config they are running, god bless them.

It is not just for meltdown (kpti). You also have retpoline and IBRS
which is for spectre.

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Alexey Dobriyan]

Thomas Gleixner wrote:
> Create /sys/devices/system/cpu/vulnerabilities folder and files for
> meltdown, spectre_v1 and spectre_v2.

It is called "grep -e '^bugs' /proc/cpuinfo".

kpti is deduceable from .config and /proc/cmdline .
If people don't know what .config they are running, god bless them.

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Alexey Dobriyan]

Thomas Gleixner wrote:
> Create /sys/devices/system/cpu/vulnerabilities folder and files for
> meltdown, spectre_v1 and spectre_v2.

It is called "grep -e '^bugs' /proc/cpuinfo".

kpti is deduceable from .config and /proc/cmdline .
If people don't know what .config they are running, god bless them.

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Konrad Rzeszutek Wilk]

On Sun, Jan 07, 2018 at 10:48:00PM +0100, Thomas Gleixner wrote:
> As the meltdown/spectre problem affects several CPU architectures, it makes
> sense to have common way to express whether a system is affected by a
> particular vulnerability or not. If affected the way to express the
> mitigation should be common as well.
> 
> Create /sys/devices/system/cpu/vulnerabilities folder and files for
> meltdown, spectre_v1 and spectre_v2.
> 
> Allow architectures to override the show function.
> 
> Signed-off-by: Thomas Gleixner 
> ---
>  Documentation/ABI/testing/sysfs-devices-system-cpu |   16 +++
>  drivers/base/Kconfig   |3 +
>  drivers/base/cpu.c |   48 
> +
>  include/linux/cpu.h|7 +++
>  4 files changed, 74 insertions(+)
> 
> --- a/Documentation/ABI/testing/sysfs-devices-system-cpu
> +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
> @@ -373,3 +373,19 @@ Contact: Linux kernel mailing list   Description: information about CPUs heterogeneity.
>  
>   cpu_capacity: capacity of cpu#.
> +
> +What:/sys/devices/system/cpu/vulnerabilities
> + /sys/devices/system/cpu/vulnerabilities/meltdown
> + /sys/devices/system/cpu/vulnerabilities/spectre_v1
> + /sys/devices/system/cpu/vulnerabilities/spectre_v2
> +Date:Januar 2018

s/Januar/January/

and with that
Reviewed-by: Konrad Rzeszutek Wilk 

Thank you!
> +#ifdef CONFIG_GENERIC_CPU_VULNERABILITIES
> +
> +ssize_t __weak cpu_show_meltdown(struct device *dev,
> +  struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "Not affected\n");
> +}
> +
> +ssize_t __weak cpu_show_spectre_v1(struct device *dev,
> +struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "Not affected\n");
> +}
> +
> +ssize_t __weak cpu_show_spectre_v2(struct device *dev,
> +struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "Not affected\n");
> +}
> +
> +static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL);
> +static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL);
> +static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL);
> +
> +static struct attribute *cpu_root_vulnerabilities_attrs[] = {
> + _attr_meltdown.attr,
> + _attr_spectre_v1.attr,
> + _attr_spectre_v2.attr,
> + NULL
> +};
> +
> +static const struct attribute_group cpu_root_vulnerabilities_group = {
> + .name  = "vulnerabilities",
> + .attrs = cpu_root_vulnerabilities_attrs,
> +};
> +
> +static void __init cpu_register_vulnerabilities(void)
> +{
> + if (sysfs_create_group(_subsys.dev_root->kobj,
> +_root_vulnerabilities_group))
> + pr_err("Unable to register CPU vulnerabilities\n");
> +}
> +
> +#else
> +static inline void cpu_register_vulnerabilities(void) { }
> +#endif
> +
>  void __init cpu_dev_init(void)
>  {
>   if (subsys_system_register(_subsys, cpu_root_attr_groups))
>   panic("Failed to register CPU subsystem");
>  
>   cpu_dev_register_generic();
> + cpu_register_vulnerabilities();
>  }
> --- a/include/linux/cpu.h
> +++ b/include/linux/cpu.h
> @@ -47,6 +47,13 @@ extern void cpu_remove_dev_attr(struct d
>  extern int cpu_add_dev_attr_group(struct attribute_group *attrs);
>  extern void cpu_remove_dev_attr_group(struct attribute_group *attrs);
>  
> +extern ssize_t cpu_show_meltdown(struct device *dev,
> +  struct device_attribute *attr, char *buf);
> +extern ssize_t cpu_show_spectre_v1(struct device *dev,
> +struct device_attribute *attr, char *buf);
> +extern ssize_t cpu_show_spectre_v2(struct device *dev,
> +struct device_attribute *attr, char *buf);
> +
>  extern __printf(4, 5)
>  struct device *cpu_device_create(struct device *parent, void *drvdata,
>const struct attribute_group **groups,
> 
> 

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Konrad Rzeszutek Wilk]

On Sun, Jan 07, 2018 at 10:48:00PM +0100, Thomas Gleixner wrote:
> As the meltdown/spectre problem affects several CPU architectures, it makes
> sense to have common way to express whether a system is affected by a
> particular vulnerability or not. If affected the way to express the
> mitigation should be common as well.
> 
> Create /sys/devices/system/cpu/vulnerabilities folder and files for
> meltdown, spectre_v1 and spectre_v2.
> 
> Allow architectures to override the show function.
> 
> Signed-off-by: Thomas Gleixner 
> ---
>  Documentation/ABI/testing/sysfs-devices-system-cpu |   16 +++
>  drivers/base/Kconfig   |3 +
>  drivers/base/cpu.c |   48 
> +
>  include/linux/cpu.h|7 +++
>  4 files changed, 74 insertions(+)
> 
> --- a/Documentation/ABI/testing/sysfs-devices-system-cpu
> +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
> @@ -373,3 +373,19 @@ Contact: Linux kernel mailing list   Description: information about CPUs heterogeneity.
>  
>   cpu_capacity: capacity of cpu#.
> +
> +What:/sys/devices/system/cpu/vulnerabilities
> + /sys/devices/system/cpu/vulnerabilities/meltdown
> + /sys/devices/system/cpu/vulnerabilities/spectre_v1
> + /sys/devices/system/cpu/vulnerabilities/spectre_v2
> +Date:Januar 2018

s/Januar/January/

and with that
Reviewed-by: Konrad Rzeszutek Wilk 

Thank you!
> +#ifdef CONFIG_GENERIC_CPU_VULNERABILITIES
> +
> +ssize_t __weak cpu_show_meltdown(struct device *dev,
> +  struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "Not affected\n");
> +}
> +
> +ssize_t __weak cpu_show_spectre_v1(struct device *dev,
> +struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "Not affected\n");
> +}
> +
> +ssize_t __weak cpu_show_spectre_v2(struct device *dev,
> +struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "Not affected\n");
> +}
> +
> +static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL);
> +static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL);
> +static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL);
> +
> +static struct attribute *cpu_root_vulnerabilities_attrs[] = {
> + _attr_meltdown.attr,
> + _attr_spectre_v1.attr,
> + _attr_spectre_v2.attr,
> + NULL
> +};
> +
> +static const struct attribute_group cpu_root_vulnerabilities_group = {
> + .name  = "vulnerabilities",
> + .attrs = cpu_root_vulnerabilities_attrs,
> +};
> +
> +static void __init cpu_register_vulnerabilities(void)
> +{
> + if (sysfs_create_group(_subsys.dev_root->kobj,
> +_root_vulnerabilities_group))
> + pr_err("Unable to register CPU vulnerabilities\n");
> +}
> +
> +#else
> +static inline void cpu_register_vulnerabilities(void) { }
> +#endif
> +
>  void __init cpu_dev_init(void)
>  {
>   if (subsys_system_register(_subsys, cpu_root_attr_groups))
>   panic("Failed to register CPU subsystem");
>  
>   cpu_dev_register_generic();
> + cpu_register_vulnerabilities();
>  }
> --- a/include/linux/cpu.h
> +++ b/include/linux/cpu.h
> @@ -47,6 +47,13 @@ extern void cpu_remove_dev_attr(struct d
>  extern int cpu_add_dev_attr_group(struct attribute_group *attrs);
>  extern void cpu_remove_dev_attr_group(struct attribute_group *attrs);
>  
> +extern ssize_t cpu_show_meltdown(struct device *dev,
> +  struct device_attribute *attr, char *buf);
> +extern ssize_t cpu_show_spectre_v1(struct device *dev,
> +struct device_attribute *attr, char *buf);
> +extern ssize_t cpu_show_spectre_v2(struct device *dev,
> +struct device_attribute *attr, char *buf);
> +
>  extern __printf(4, 5)
>  struct device *cpu_device_create(struct device *parent, void *drvdata,
>const struct attribute_group **groups,
> 
>