Hi, Thanks for taking a look at this: On 2/15/19 12:20 PM, Catalin Marinas wrote: > On Wed, Jan 30, 2019 at 06:04:15PM +0000, Andre Przywara wrote: >> On Fri, 25 Jan 2019 12:07:02 -0600 >> Jeremy Linton <jeremy.linton at arm.com> wrote: >>> Buried behind EXPERT is the ability to build a kernel without >>> SSBD, this needlessly clutters up the code as well as creates >>> the opportunity for bugs. It also removes the kernel's ability >>> to determine if the machine its running on is vulnerable. >> >> I don't know the original motivation for this config option, typically >> they are not around for no reason. >> I see the benefit of dropping those config options, but we want to make >> sure that people don't start hacking around to remove them again. >> >>> Since its also possible to disable it at boot time, lets remove >>> the config option. >> >> Given the level of optimisation a compiler can do with the state being >> known at compile time, I would imagine that it's not the same (though >> probably very close). >> >> But that's not my call, it would be good to hear some maintainer's >> opinion on this. > > Having spoken to Will, we'd rather keep the config options if possible. > Even if they are behind EXPERT and default y, they come in handy when > debugging. > > Can we still have the sysfs information regardless of whether the config > is enabled or not? IOW, move the #ifdefs around to always have the > detection while being able to disable the actual workarounds via config? Yes, that is possible, but the ifdef'ing gets even worse. (see v3). > Are the code paths between config and cmdline disabling identical? At a > quick look I got the impression they are not exactly the same. No, they do vary slightly. For debugging I would expect that the CONFIG disabled code paths to be the one that accumulates bugs over time. The command line options just force the runtime vulnerable/not-vulnerable decision, which should be the code paths in general use. For benchmark the run-time options are also a better choice because they don't have any 2nd order affects caused by code alignment/etc changes. Maybe your implying the CONFIG_ options should basically force the command line? That both reduces the code paths, and simplifies the ifdef'ing.
