Messages in this thread |  | | Date | Mon, 8 Jan 2018 08:33:43 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder |
| |
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 <tglx@linutronix.de> > > --- > > 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 <linu > > 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 <linux-kernel@vger.kernel.org> > > +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
|  |