x86: AMD Zen2: Zenbleed chicken bit mitigation

[olce]

Summary

Applies only to bare-metal Zen2 processors. The system currently automatically
applies it to all of them.

Tunable/sysctl 'machdep.mitigations.zenbleed.enable' can be used to forcibly
enable or disable the mitigation at boot or run-time. Possible values are: 0:
Mitigation disabled, 1: Mitigation enabled, 2: Run the automatic determination.
Currently, value 2 is the default and has identical effect as value 1. This
might change in the future if we choose to take into account microcode revisions
in the automatic determination process.

The tunable/sysctl value is simply ignored on non-applicable CPU models, which
is useful to apply the same configuration on a set of machines that do not all
have Zen2 processors. Trying to set it to any integer value not listed above is
silently equivalent to setting it to value 2 (automatic determination).

The current mitigation state can be queried through sysctl
'machdep.mitigations.zenbleed.state', which returns "Not applicable",
"Mitigation enabled" or "Mitigation disabled". Note that this state is not
guaranteed to be accurate in case of intervening modifications of the
corresponding chicken bit directly via cpuctl(4) (this includes the
cpucontrol(8) utility). Resetting the desired policy through
'machdep.mitigations.zenbleed.enable' (possibly to its current value) will reset
the hardware state and ensure that the reported state is again coherent with it.

Sponsored by: The FreeBSD Foundation

[kib]

There is security(7)

[emaste]

Also, I started writing a mitigations.7 in D41794

[emaste]

This change felt a little bit verbose to me, compared to the equivalent Linux change. But, I think we do want to rationalize all of the mitigations and make the enables consistent so that they all have off / on / automatic, with the intent that in a normal configuration all can be set to automatic. And we should report status as off (forced), off (does not apply to this hw), etc. So all of that said I think this is fine and may be a good starting point for more common mitigation controls.

[olce]

In D41817#955230, @emaste wrote:

This change felt a little bit verbose to me, compared to the equivalent Linux change. But, I think we do want to rationalize all of the mitigations and make the enables consistent so that they all have off / on / automatic, with the intent that in a normal configuration all can be set to automatic. And we should report status as off (forced), off (does not apply to this hw), etc. So all of that said I think this is fine and may be a good starting point for more common mitigation controls.

I agree. It would be great that both the administrative handling of mitigations (the different knobs, for control and reporting) and how they are internally applied are factored out, with the benefits of consistency for users and having to patch less locations for developers. I'll probably give a shot as a follow-up, but I don't plan to do it immediately.