Hello Yafang, On Mon, Oct 23, 2023 at 10:59:13AM +0800, Yafang Shao wrote: > On Fri, Oct 20, 2023 at 2:12 AM Breno Leitao <leitao@xxxxxxxxxx> wrote: > > > > Currently, the CONFIG_SPECULATION_MITIGATIONS is halfway populated, > > where some mitigations have entries in Kconfig, and they could be > > modified, while others mitigations do not have Kconfig entries, and > > could not be controlled at build time. > > > > The fact of having a fine grained control can help in a few ways: > > > > 1) Users can choose and pick only mitigations that are important for > > their workloads. > > > > 2) Users and developers can choose to disable mitigations that mangle > > the assembly code generation, making it hard to read. > > > > 3) Separate configs for just source code readability, > > so that we see *which* butt-ugly piece of crap code is for what > > reason. > > > > Important to say, if a mitigation is disabled at compilation time, it > > could be enabled at runtime using kernel command line arguments. > > Hi Breno, > > Do you have any plans to introduce utility functions for runtime > checks on whether specific mitigations are disabled? Such helpers > would be quite valuable; for instance, we could utilize them to > determine if Spectre v1 or Spectre v4 mitigations are disabled in > BPF[1]. I am not planning to. The check if a mitigation is enabled or not is a different topic, that also might require some further refactor. This patch set focuses in the initialization of the mitigation code at build time. Initializating the mitigation code might not result in the mitigation being enabled in runtime. For instance, you can build the kernel to mitigate the GDS, but the runtime detects that you are running in a guest VM, and depend on the host to do the mitigation, so, the mitigation might be enabled or not, even if it is initialized with CONFIG_GDS_FORCE_MITIGATION=y. Detecting if the mitigation is enabled or not is an orthogonal problem than the one I am trying to solve with this patch set.
