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

From: Alexey Dobriyan <adobriyan@gmail.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, linux-kernel@vger.kernel.org
Subject: Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder
Date: Mon, 8 Jan 2018 12:30:41 +0200	[thread overview]
Message-ID: <CACVxJT9SATrGjDkKAw_gs0NgNXFQzLf=V3eNrpoZHRCv6JCK5A@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1801081036100.1735@nanos>

On 1/8/18, Thomas Gleixner <tglx@linutronix.de> 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).