That's a very old CPU so I don't think you'll ever get microcode for SSB and MDS mitigations to work.

The ITLB multihit thing needs KVM but your CPU doesn't even have hardware virtualization support. But if you don't run guests on it, I wouldn't worry about it.

HTH.

What about kernel-level mitigations? Are these impossible, i.e. is microcode the only way to mitigate the remaining vulnerabilities?

> But if you don't run guests on it, I wouldn't worry about it.

What about web JavaScript? I have read (and seen Google's presentation) that it is possible web JS to read the RAM. This is quite worrying.

(In reply to Suse User from comment #2)
> What about kernel-level mitigations? Are these impossible, i.e. is microcode
> the only way to mitigate the remaining vulnerabilities?

Yes.

> What about web JavaScript? I have read (and seen Google's presentation) that
> it is possible web JS to read the RAM. This is quite worrying.

Which presentation is that? Link?

> Yes.

That's quite unfortunate.

> Which presentation is that? Link?

https://spectreattack.com/spectre.pdf
https://invidio.us/watch?v=6O8LTwVfTVs

I also asked about this on LKML hoping for some clarity from experts but unfortunately got zero replies (and unsubscribed from that list):

https://lkml.org/lkml/2019/12/8/205

I would really appreciate if you could direct me to the right info (or the right place to ask).

(In reply to Suse User from comment #4)
> https://spectreattack.com/spectre.pdf
> https://invidio.us/watch?v=6O8LTwVfTVs

I think you misunderstood. My comment about running guests was about the ITLB multihit thing. The pointers you gave are about Spectre and Meltdown - which are not the ITLB multihit thing and they are not part of your question in the description. So what exactly are you asking?

I suppose the confusion comes from this bug report being about other vulnerabilities too (as seen in the initial attachment):

# with kernel-default:

- l1tf
- mds
- meltdown
- spectre store bypass
+ itlb multihit

# with kernel-pae (fewer but still not fully mitigated):

- mds
- spectre store bypass
+ itlb multihit

Considering this difference between kernel-default and kernel-pae + the fact that the microcode is the same whether I use either kernel: I thought that some of the vulnerabilities are not just a matter of microcode but kernel level mitigations exists.

> So what exactly are you asking?

(1) After the above clarification, I suppose you can have a second look to my previous question.

> > What about kernel-level mitigations? Are these impossible, i.e. is microcode
> > the only way to mitigate the remaining vulnerabilities?

(2) My other question is:

https://lkml.org/lkml/2019/12/8/205

*I understand (2) and the answer to it may be considered off-topic to this bug report but I still hope you could shed some light on it too (in direct email is fine too, if you think it would be more appropriate).

(In reply to Suse User from comment #6)
> (1) After the above clarification, I suppose you can have a second look to
> my previous question.

Hardly a clarification because I still have no clue what exactly you're
asking. If you want an answer to something, please formulate it as an
exact question.

> (2) My other question is:
> 
> https://lkml.org/lkml/2019/12/8/205
> 
> *I understand (2) and the answer to it may be considered off-topic to this
> bug report but I still hope you could shed some light on it too (in direct
> email is fine too, if you think it would be more appropriate).

AFAIU, you're asking whether you can do something additional as a user
in case Spectre and Meltdown are not mitigated on your CPU. But they
*are* mitigated, on *your* machine:

/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, STIBP: disabled, RSB filling

> If you want an answer to something, please formulate it as an
> exact question.

- Why are L1TF and Meltdown not mitigated in kernel-default but only in
  kernel-pae?

- Is it possible to mitigate MDS and 'Spec store bypass' through kernel
  or only through microcode?

- Can L1TF, MDS or 'Spec store bypass' be exploited through web
  JavaScript, like shown in the video/papers?

> AFAIU, you're asking whether you can do something additional as a user
> in case Spectre and Meltdown are not mitigated on your CPU. But they
> *are* mitigated, on *your* machine:

The 2-part general question asked on LKML is about any system with a
vulnerable CPU hradware. It arises from the following:

A. Mitigations for some systems may not exist
B. Mitigations may exist but they are not complete fixes, as papers say
C. Browser-level mitigations are like B.

Therefore:

D. Web JavaScript (and WebAssemby) can be dangerous and one cannot
possibly verify manually each and every script while browsing the web

E. Unfortunately there are websites which don't work with JS disabled

Based on that I have formulated the 2 questions on LKML:

https://lkml.org/lkml/2019/12/8/205

> - Why are L1TF and Meltdown not mitigated in kernel-default but only in
>   kernel-pae?

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=61a6bd83abf2f14b2a917b6a0279c88d299267af

> - Is it possible to mitigate MDS and 'Spec store bypass' through kernel
>   or only through microcode?

As previously stated, only through microcode update.

> - Can L1TF, MDS or 'Spec store bypass' be exploited through web
>   JavaScript, like shown in the video/papers?

L1TF: https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html#mitigation-selection-guide
MDS: https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html#attack-scenarios
SSB: https://software.intel.com/security-software-guidance/software-guidance/speculative-store-bypass

> https://lkml.org/lkml/2019/12/8/205

The section "Process Isolation" here

https://software.intel.com/security-software-guidance/software-guidance/speculative-store-bypass

kinda explains what you need to do.

The section "Web-Browsers" here

https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html#attack-scenarios

says that MDS exploitation through JS is highly-unlikely.

The section "Mitigation selection guide" here

https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html#mitigation-selection-guide

says that if you don't use virtualization, the system is protected, as I
already pointed out previously.

And that's all the answers I can give you: I cannot tell you just by
describing what you do whether what you do is absolutely secure. Maybe,
maybe not. I also cannot tell you how likely is a "highly-unlikely"
exploitation. I don't think anyone would give you guarantees here.

What I can tell you is that we do our best to have the kernel up-to-date
and contain the latest mitigations.

I sincerely hope that helps.

Thank you for this info.

From the answers I understand it is a very complex field in which definitive answers cannot be given. I guess that although some things may be "highly unlikely" it is still a good idea to keep any technology which allows downloading and running unverified/utrusted code disabled by default (be it web JS, WASM or anything else).

I hope RISC-V will change the world of computers. ;)

Thanks!

(In reply to Suse User from comment #10)
> Thank you for this info.
> 
> From the answers I understand it is a very complex field in which definitive
> answers cannot be given. I guess that although some things may be "highly
> unlikely" it is still a good idea to keep any technology which allows
> downloading and running unverified/utrusted code disabled by default (be it
> web JS, WASM or anything else).

You can always get a newer CPU for which there is microcode or get an AMD machine which is affected by less issues:

/sys/devices/system/cpu/vulnerabilities/itlb_multihit:Not affected
/sys/devices/system/cpu/vulnerabilities/l1tf:Not affected
/sys/devices/system/cpu/vulnerabilities/mds:Not affected
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline, IBPB: conditional, STIBP: disabled, RSB filling
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Not affected

> I hope RISC-V will change the world of computers. ;)

I wouldn't put my hopes up. I'm pretty sure they'll screw it up in their own way. :-)

Ok, we're done here, closing.

> You can always get a newer CPU for which there is microcode

Unfortunately a newer CPU means Intel ME (or AMD's analog of it) - something which I am lucky not to have on that old machine which has never had it.

> or get an AMD machine which is affected by less issues:

Which CPU is that please? (Last question, I promise)

(In reply to Suse User from comment #12)
> Which CPU is that please? (Last question, I promise)

That is Zen, family 0x17.

Thank you!

You said that 'spec store bypass' and MDS can be mitigated only through microcode update.

According to this material which explains that both vulnerabilities are domain-bypass:

https://software.intel.com/security-software-guidance/insights/refined-speculative-execution-terminology

"If a vulnerability is described as having domain-bypass impact, then hardware mitigation, microcode patches and/or software changes to the operating system (OS) or virtual machine monitor (VMM) are often required."

Trying to understand what "and/or" may include I looked at the individual articles for each vulnerability.

This info:

https://software.intel.com/security-software-guidance/software-guidance/speculative-store-bypass#mitigation

says that:

"Speculative store bypass can be mitigated through software-based approaches including process isolation and selective use of LFENCE."

And for MDS:

https://software.intel.com/security-software-guidance/software-guidance/microarchitectural-data-sampling#mitigation

"For processors that are affected, the mitigation for microarchitectural data sampling issues includes overwriting store buffers, fill buffers, and load ports before transitioning to possibly less-privileged code."

which also sounds like a software mitigation.

I would like to kindly ask the experts here to please review this info and consider the possibility of implementing OS based mitigations which according to Intel are possible.

I believe Boris provided exhaustive answers to your questions. Upstream documentation provides all information about the current implementation of all these mitigations. We try really hard to follow upstream here. If I recall correctly, software mitigations were discussed in some cases, but they were not implemented, because of another issues they have (performance, not reliable and such).

Boris (or someone else) could add more specific info eventually if they like, but I think we're done here.

> I believe Boris provided exhaustive answers to your questions.

Yes.

> Upstream documentation provides all information about the current implementation of all these mitigations. We try really hard to follow upstream here. If I recall correctly, software mitigations were discussed in some cases, but they were not implemented, because of another issues they have (performance, not reliable and such).

Indeed the documentation provides info and Intel itself confirms that software-based mitigation is possible. Performance hit or not - if it is possible, why not have it and let the user decide whether to enable it or not (e.g. through a boot flag)? There are use cases where security is more important than speed and vice versa. Assuming that only the later is the preferred choice for everyone is not really correct. Let's please not forget that these issues exist exactly because of this such assumption.

You are welcome to report upstream, but I am confident you will fail there, because of the reasons provided here. The microcode mitigation is a standard way to deal with these issues and it is in most cases the only reliable way. Introducing a sub-optimal solution next to the standard one is not how the upstream development works.

OK, reported upstream:

https://bugzilla.kernel.org/show_bug.cgi?id=210473

And with the upstream report...