/sys/devices/system/cpu/vulnerabilities/ doesn't show all known CPU vulnerabilities

/sys/devices/system/cpu/vulnerabilities/ doesn't show all known CPU vulnerabilities

[Kernel User]

Hi,

'ls /sys/devices/system/cpu/vulnerabilities/' doesn't show all known
CPU vulnerabilities and their variants. Only some of them:

l1tf  mds  meltdown  spec_store_bypass  spectre_v1  spectre_v2

Wikipedia shows more variants:

https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)#Speculative_execution_security_vulnerabilities

It would be good to have a full list with statuses. Then one won't need to use external (potentially non-safe) tools like https://github.com/speed47/spectre-meltdown-checker to find out the vulnerabilities of a system.


This started as a feature request on openSUSE's bugzilla where it was
suggested to report it here:

http://bugzilla.suse.com/show_bug.cgi?id=1145191

Re: /sys/devices/system/cpu/vulnerabilities/ doesn't show all known CPU vulnerabilities

[Borislav Petkov]

On Tue, Aug 13, 2019 at 11:28:29PM +0300, Kernel User wrote:
> Hi,
> 
> 'ls /sys/devices/system/cpu/vulnerabilities/' doesn't show all known
> CPU vulnerabilities and their variants. Only some of them:
> 
> l1tf  mds  meltdown  spec_store_bypass  spectre_v1  spectre_v2
> 
> Wikipedia shows more variants:
> 
> https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)#Speculative_execution_security_vulnerabilities
> 
> It would be good to have a full list with statuses. Then one won't need to use external (potentially non-safe) tools like https://github.com/speed47/spectre-meltdown-checker to find out the vulnerabilities of a system.
> 

You have to consider that some of those are addressed by a single
mitigation like MDS; the mitigation for others like lazy FPU restore
is not even present in /sys/devices/system/cpu/vulnerabilities/. Also,
depending on the CPU, some are not even affected.

So maintaining this in the kernel is unnecessary to say the least.

We could use a writeup somewhere which maps each vulnerability name -
and they're a gazillion by now - to the respective mitigation and what
is required but I'm not aware of such a writeup.

Documentation/admin-guide/hw-vuln/ could be a good start and
Documentation/admin-guide/hw-vuln/mds.rst could be a good example how
one should document the vulnerabilities and their mitigation. But that
would need to be exhaustive.

IMHO of course.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: /sys/devices/system/cpu/vulnerabilities/ doesn't show all known CPU vulnerabilities

[Kernel User]

On Tue, 13 Aug 2019 23:21:15 +0200 Borislav Petkov wrote:

> You have to consider that some of those are addressed by a single
mitigation like MDS

That could be clarified like:

vulnerability1 - mitigation MDS
vulnerability2 - mitigation MDS
vulnerability3 - mitigation 3 (another mitigation)
...

> the mitigation for others like lazy FPU restore is not even present
> in /sys/devices/system/cpu/vulnerabilities/.

Then it could be a file with content saying "No mitigation".

> Also, depending on the CPU, some are not even affected.

That could say "Not affected" (which AFAIK is the case for some cases).

> So maintaining this in the kernel is unnecessary to say the least.

Knowing that there is no mitigation or that a CPU is not affected is
quite different from not knowing anything. So I don't see why you
conclude that knowledge is unnecessary.

Re: /sys/devices/system/cpu/vulnerabilities/ doesn't show all known CPU vulnerabilities

[Borislav Petkov]

On Wed, Aug 14, 2019 at 01:00:41AM +0300, Kernel User wrote:
> That could be clarified like:
> 
> vulnerability1 - mitigation MDS
> vulnerability2 - mitigation MDS
> vulnerability3 - mitigation 3 (another mitigation)
> ...
>
> Then it could be a file with content saying "No mitigation".

And keep adding a sysfs file for each new variant and CVE?

Hell no.

> Knowing that there is no mitigation or that a CPU is not affected is
> quite different from not knowing anything. So I don't see why you
> conclude that knowledge is unnecessary.

IMO, what you want does not belong in sysfs but in documentation.

I partially see your point that a table of sorts mapping all those CPU
vulnerability names to (possible) mitigations is needed for users which
would like to know whether they're covered, without having to run some
scripts from github, but sysfs just ain't the place.

Again, this is only my opinion.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: /sys/devices/system/cpu/vulnerabilities/ doesn't show all known CPU vulnerabilities

[Kernel User]

On Wed, 14 Aug 2019 09:04:57 +0200 Borislav Petkov wrote:

> IMO, what you want does not belong in sysfs but in documentation.

How would documentation (a fixed static text file) tell whether a
particular system is vulnerable or not?

> I partially see your point that a table of sorts mapping all those CPU
> vulnerability names to (possible) mitigations is needed for users
> which would like to know whether they're covered, without having to
> run some scripts from github,

Correct.

> but sysfs just ain't the place.

Then why is it currently used for some of the vulnerabilities?

I am not an expert and I don't know if it is the place. My only concern
is to have that information which we currently don't regardless of
where it may be placed.

Re: /sys/devices/system/cpu/vulnerabilities/ doesn't show all known CPU vulnerabilities

[Thomas Gleixner]

On Wed, 14 Aug 2019, Kernel User wrote:
> On Wed, 14 Aug 2019 09:04:57 +0200 Borislav Petkov wrote:
> 
> > IMO, what you want does not belong in sysfs but in documentation.
> 
> How would documentation (a fixed static text file) tell whether a
> particular system is vulnerable or not?
> 
> > I partially see your point that a table of sorts mapping all those CPU
> > vulnerability names to (possible) mitigations is needed for users
> > which would like to know whether they're covered, without having to
> > run some scripts from github,
> 
> Correct.
> 
> > but sysfs just ain't the place.
> 
> Then why is it currently used for some of the vulnerabilities?

It's used to denote vulnerability classes and their mitigations:

  - Spectre v1
  - Spectre v2
  - Meltdown
  - SSB
  - L1TF
  - MDS

We are not tracking subclasses and their individual CVEs. The sysfs
interface is accurate (including SMT state) and the mapping to subclasses
and CVEs can be done by user space tools if required.

Thanks,

	tglx

Re: /sys/devices/system/cpu/vulnerabilities/ doesn't show all known CPU vulnerabilities

[Kernel User]

On Thu, 15 Aug 2019 11:03:35 +0200 (CEST) Thomas Gleixner wrote:

> It's used to denote vulnerability classes and their mitigations:
> 
>   - Spectre v1
>   - Spectre v2
>   - Meltdown
>   - SSB
>   - L1TF
>   - MDS

In the Wikipedia article there are:

+ Bounds Check Bypass (Spectre, Variant 1)
+ Branch Target Injection (Spectre, Variant 2)
+ Rogue Data Cache Load (Meltdown, Variant 3)
- Rogue System Register Read (Spectre-NG, Variant 3a)
+ Speculative Store Bypass (Spectre-NG, Variant 4)
- Lazy FP state restore (Spectre-NG)
- Bounds Check Bypass Store (Spectre-NG)
+ Foreshadow
- Spoiler
+ Microarchitectural Data Sampling

I have marked with '+' those which I recognize in the list you provided
and with '-' those which are not.

> We are not tracking subclasses and their individual CVEs.

Why do you say that? In your list only L1TF and MDS are not subclasses,
i.e. subclasses are in the list. So why not have the others? Also
Spoiler seems to be a separate class.

Re: /sys/devices/system/cpu/vulnerabilities/ doesn't show all known CPU vulnerabilities

[Thomas Gleixner]

On Thu, 15 Aug 2019, Kernel User wrote:
> On Thu, 15 Aug 2019 11:03:35 +0200 (CEST) Thomas Gleixner wrote:
> 
> > It's used to denote vulnerability classes and their mitigations:
> > 
> >   - Spectre v1
> >   - Spectre v2
> >   - Meltdown
> >   - SSB
> >   - L1TF
> >   - MDS
> 
> In the Wikipedia article there are:
> 
> + Bounds Check Bypass (Spectre, Variant 1)
> + Branch Target Injection (Spectre, Variant 2)
> + Rogue Data Cache Load (Meltdown, Variant 3)
> - Rogue System Register Read (Spectre-NG, Variant 3a)

Is a subclass of Meltdown, but cannot be mitigated in software and we don't
know whether the micro-code contains a fix or not unless the CPU/microcode
tells us that Meltdown is fixed, which includes 3a. We report that
correctly.

It's also not a really spectacular issue. The only valuable data you might
get out of it is info to break KASLR, but there are a gazillion other ways
to do so.

> + Speculative Store Bypass (Spectre-NG, Variant 4)
> - Lazy FP state restore (Spectre-NG)

The kernel is not using lazy restore. Dead kernels did, but they got
patched and no longer allow the lazy mode. So, nothing to see here.

> - Bounds Check Bypass Store (Spectre-NG)

Is a subclass of Spectre V1 similar to the recently published SWAPGS issue.

> + Foreshadow
> - Spoiler

Spoiler cannot be mitigated by any means. It's like Rowhammer. Nothing we
can do about and nothing to show.

> + Microarchitectural Data Sampling
> 
> I have marked with '+' those which I recognize in the list you provided
> and with '-' those which are not.
> 
> > We are not tracking subclasses and their individual CVEs.
> 
> Why do you say that? In your list only L1TF and MDS are not subclasses,
> i.e. subclasses are in the list. So why not have the others? Also
> Spoiler seems to be a separate class.

What? Spectre V1, V2 and Meltdown and SSB are different classes despite the
variant 1,2,3,4 enumeration. They are different classes because they
utilize different parts of the whole speculative execution machinery and
need very different mitigation mechanisms.

Just because Wikipedia has a list of some sort does not mean that we have
to blindly follow it.

Thanks,

	tglx

Re: /sys/devices/system/cpu/vulnerabilities/ doesn't show all known CPU vulnerabilities

[Kernel User]

Thomas Gleixner,

Alright. Then I guess I am wasting everyone's time and everything is as
it should be according to you.

I will unsubscribe from this mailing list because it is flooding my
mail box with so many messages and I don't know of any way to subscribe
only to this particular thread.

Please CC me if this discussion continues.