Repository navigation
use SRSO spec_rstack_overflow kernel setting? #177
Description
Activity
sudo dmesg | grep -i speculativespectre_v2_user=seccomp,ibpb
seccomp,ibpb - Like "seccomp" above, but only STIBP is controlled per thread. IBPB is issued always when switching between different user space processes.The word "only" is concerning?
This seems a weaker setting than:
on - Unconditionally enable mitigations. Is enforced by spectre_v2=onmitigations=auto,nosmtsounds good.auto,nosmt Mitigate all CPU vulnerabilities, disabling SMT if needed. This is for users who always want to be fully mitigated, even if it means losing SMT. Equivalent to: l1tf=flush,nosmt [X86] mds=full,nosmt [X86] tsx_async_abort=full,nosmt [X86] mmio_stale_data=full,nosmt [X86] retbleed=auto,nosmt [X86]It might obsolete a few of our other settings.
Not sure what you're suggesting? Setting
spectre_v2_user=seccomp,ibpb? Why would we weaken the settings?To make sure something is enabled rather than nothing? That would be the wrong approach.
verification: Better to ask the kernel from within the running system by using the usual API (/proc or /sys) if mitigation are enabled. This kind of testing, confirmation would be a job for systemcheck.
We could drop most and use
mitigations=auto,nosmtinstead. Everything that is covered bymitigations=does not need to be duplicated. Since we don't have verification it's still non-ideal but acceptable. Still flying blind.mitigations=auto,nosmtis nice and we can enable it. Quote:auto,nosmt Mitigate all CPU vulnerabilities, disabling SMT if needed. This is for users who always want to be fully mitigated, even if it means losing SMT. Equivalent to: l1tf=flush,nosmt [X86] mds=full,nosmt [X86] tsx_async_abort=full,nosmt [X86] mmio_stale_data=full,nosmt [X86] retbleed=auto,nosmt [X86]but
mitigations=auto,nosmtkernel manual does not mentionspec_rstack_overflow. Explicitly settingspec_rstack_overflowmight be more secure.Note,
-
Speculative Return Stack Overflow (SRSO) (
spec_rstack_overflow) vs -
vs Spectre (
spectre_v2)
It's not the same. Both have their own dedicated kernel manual page.
-
Comparing to we already have in our configuration, we seem to be explicitly missing:
-
retbleed=auto,nosmt: This should be added. -
spec_rstack_overflow=ibpborspec_rstack_overflow=safe-ret: I am not certain which one is superior for our explicit purposes. I think the first is probably better.
As you have stated, using
mitigations=auto,nosmtis probably a good idea. While it would obsolete existing settings, I don’t think any harm will come since we use the same equivalent settings.Perhaps we should place this kernel parameter at the top of the configuration so it is applied first and then reinforced by our already more fine-grained settings?
This way we will inherit any future mitigation from this kernel parameter that are not explicitly specified while also keeping our strict fine-grained settings fixed.
Finally , since
spec_rstack_overflowis not explicitly mentioned inmitigations, I believe we should put it in directly just to be safe.-
retbleed=auto,nosmt: This should be added.
Ok.
spec_rstack_overflow=ibpborspec_rstack_overflow=safe-ret: I am not certain which one is superior for our explicit purposes. I think the first is probably better.
If we don't know it, we should ask somewhere. Short of an obvious answer or expert opinion, without being sure, we better keep it as is.
The kernel built-in default setting might actually already be the most secure setting.
As you have stated, using
mitigations=auto,nosmtis probably a good idea.Ok.
Perhaps we should place this kernel parameter at the top of the configuration so it is applied first and then reinforced by our already more fine-grained settings?
Ok.
I have left that parameter as the default kernel mitigation:
spec_rstack_overflow=safe-ret?If we don't know a more safe setting than the default, we could as well as leave the default?
Not sure that will ever happen here but generally if the kernel gets a better, more secure default, we wouldn't want to have hardcoded it.
So as a general rule I guess brevity as in not configuring things which have no effect should be preferred.I'll leave it in for clarity but remove the hard-coding while providing an explanation.
Thoughts?
The updated, linked PR (which no longer touched
spec_rstack_overflow) looks good now.Keeping that PR a few days longer open to see if there's any other feedback.
Was merged and seems reflecting consensus.
Please re-open or create a new issue should there still be something to cover.
To test:
https://kernel.org/doc/html/latest/admin-guide/hw-vuln/srso.html
Best to use
spec_rstack_overflow=ibpb?Or not needed because we're already using
spec_store_bypass_disable=on?