Messages in this thread | | | Date | Tue, 17 Oct 2023 10:15:05 -0700 | From | Josh Poimboeuf <> | Subject | Re: [PATCH v4] x86/bugs: Add a separate config for each mitigation |
| |
On Mon, Oct 16, 2023 at 11:45:38AM +0200, Ingo Molnar wrote: > * Josh Poimboeuf <jpoimboe@kernel.org> wrote: > > On Fri, Oct 13, 2023 at 12:50:59PM +0200, Ingo Molnar wrote: > > > * Josh Poimboeuf <jpoimboe@kernel.org> wrote: > > > > On Thu, Oct 12, 2023 at 08:51:24PM +0200, Ingo Molnar wrote: > > > > > > Another way to avoid ifdeffery: > > > > > > > > > > > > static enum retbleed_mitigation_cmd retbleed_cmd __ro_after_init = > > > > > > IS_ENABLED(CONFIG_MITIGATION_RETBLEED) ? RETBLEED_CMD_AUTO : RETBLEED_CMD_OFF; > > > > > > > > > > I think we could make it a simple: > > > > > > > > > > static enum retbleed_mitigation_cmd retbleed_cmd __ro_after_init = IS_ENABLED(CONFIG_MITIGATION_RETBLEED); > > > > > > > > > > Because RETBLEED_CMD_AUTO && RETBLEED_CMD_OFF maps naturally to 1 and 0. > > > > > Maybe add a comment to the enum to maintain this property in the future > > > > > too. > > > > > > > > Hm, that both obfuscates the default and makes it fragile. The fact > > > > that it would need a comment to try to prevent breaking it in the future > > > > is a clue that maybe we shouldn't do it ;-) > > > > > > Can be enforced with BUILD_BUG_ON(). > > > > That replaces fragility with brittleness. If we change a default then > > we have to go rearrange the corresponding enum, and update the > > BUILD_BUG_ONs. > > How realistic is that? A world in which an enum named '*_OFF' isn't zero > and the most obvious second enum isn't 'auto' would be unconditionally sad > IMO...
I'm glad you asked ;-)
Not only is it realistic, it already seems to be the case for the majority of the enums which are used for defaults:
enum l1tf_mitigations { L1TF_MITIGATION_OFF, L1TF_MITIGATION_FLUSH_NOWARN, L1TF_MITIGATION_FLUSH, /* default */ L1TF_MITIGATION_FLUSH_NOSMT, L1TF_MITIGATION_FULL, L1TF_MITIGATION_FULL_FORCE };
enum taa_mitigations { TAA_MITIGATION_OFF, TAA_MITIGATION_UCODE_NEEDED, TAA_MITIGATION_VERW, /* default */ TAA_MITIGATION_TSX_DISABLED, };
enum mmio_mitigations { MMIO_MITIGATION_OFF, MMIO_MITIGATION_UCODE_NEEDED, MMIO_MITIGATION_VERW, /* default */ };
enum srbds_mitigations { SRBDS_MITIGATION_OFF, SRBDS_MITIGATION_UCODE_NEEDED, SRBDS_MITIGATION_FULL, /* default */ SRBDS_MITIGATION_TSX_OFF, SRBDS_MITIGATION_HYPERVISOR, };
enum l1d_flush_mitigations { L1D_FLUSH_OFF = 0, / * default */ L1D_FLUSH_ON, };
enum gds_mitigations { GDS_MITIGATION_OFF, GDS_MITIGATION_UCODE_NEEDED, GDS_MITIGATION_FORCE, GDS_MITIGATION_FULL, /* default */ GDS_MITIGATION_FULL_LOCKED, GDS_MITIGATION_HYPERVISOR, };
enum srso_mitigation_cmd { SRSO_CMD_OFF, SRSO_CMD_MICROCODE, SRSO_CMD_SAFE_RET, /* default */ SRSO_CMD_IBPB, SRSO_CMD_IBPB_ON_VMEXIT, };
It's dangerous (and in fact antithetical to the concept of enums!) to make assumptions about enum values, for both existing and future code.
> > More importantly, it's still less readable because the reader now has to > > go read the enum values to cross-reference the hard-coded values of 0 and > > 1 with the enums which are used everywhere else. > > They'd have to do that anyway, to make sense of the enum jungle.
Why? The enum values are completely opaque to the code as far as I can tell. Changing that will just make the code even more obtuse.
I don't see any benefit in hard-coding them. What's the point?
-- Josh
| |