> On Wed, Feb 26, 2025 at 06:45:40PM +0000, Patrick Bellasi wrote:
> > +
> > + case SRSO_CMD_BP_SPEC_REDUCE:
> > + if (boot_cpu_has(X86_FEATURE_SRSO_BP_SPEC_REDUCE)) {
> > +bp_spec_reduce:
> > + pr_notice("Reducing speculation to address VM/HV SRSO attack vector.\n");
>
> Probably not needed anymore as that will be in srso_strings which is issued
> later.
Good point, the above can certainly be dropped.
> > + srso_mitigation = SRSO_MITIGATION_BP_SPEC_REDUCE;
> > + break;
> > + } else {
> > + srso_mitigation = SRSO_MITIGATION_BP_SPEC_REDUCE_NA;
> > + pr_warn("BP_SPEC_REDUCE not supported!\n");
> > + }
>
> This is the part I'm worried about: user hears somewhere "bp-spec-reduce" is
> faster, sets it but doesn't know whether the hw even supports it. Machine
> boots, warns which is a single line and waaay buried in dmesg and continues
> unmitigated.
That's why we are also going to detect this cases and set
SRSO_MITIGATION_BP_SPEC_REDUCE_NA, so that we get a:
"Vulnerable: Reduced Speculation, not available"
from vulnerabilities/spec_rstack_overflow, which should be the only place users
look for to assess the effective mitigation posture, ins't it?
> So *maybe* we can make this a lot more subtle and say:
>
> srso=__dont_fall_back_to_ibpb_on_vmexit_if_bp_spec_reduce__
>
> (joking about the name but that should be the gist of what it means)
I can think about it, but this seems something different than the common
practice, i.e. specify at cmdline what you want and be prepares on possibly
not to get it.
> and then act accordingly when that is specified along with a big fat:
>
> WARN_ON(..."You should not use this as a mitigation option if you don't know
> what you're doing")
>
> along with a big fat splat in dmesg.
>
> Hmmm...?
After all the above already happens, e.g. if we ask for ibpb-vmexit but the
machine has not the ucode. In this case we still have to check the
vulnerabilities report to know that we are:
"Vulnerable: No microcode"
--
#include <best/regards.h>
Patrick Bellasi (derkling@)
