Re: /sys/devices/system/cpu/vulnerabilities/ doesn't show all known CPU vulnerabilities
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.
Re: /sys/devices/system/cpu/vulnerabilities/ doesn't show all known CPU vulnerabilities
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
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
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
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
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
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
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.