On 5/31/2018 5:21 PM, Michael Ellerman wrote: > Scott Wood <o...@buserror.net> writes: >> On Tue, 2018-05-29 at 15:22 +0000, Diana Madalina Craciun wrote: >>> On 05/22/2018 11:31 PM, Scott Wood wrote: >>>> Should there be a way for the user to choose not to enable this (editing >>>> the >>>> device tree doesn't count), for a use case that is not sufficiently >>>> security >>>> sensitive to justify the performance loss? What is the performance impact >>>> of >>>> this patch? >>> My reason was that on the other architectures Spectre variant 1 >>> mitigations are not disabled either. But I think that it might be a good >>> idea to add a bootarg parameter to disable the barrier. >> Is there a specific policy reason why they allow spectre v2 to be disabled >> but >> not v1, > No. > >> or just a matter of not having a mechanism to disable it, > Yes and no. Some of the v1 mitigation is done via masking which can't be > easily patched. eg. array_index_nospec() > >> or the parts which could practically be disabled not impacting >> performance much? > That's the mean reason AIUI. > > We can add a nospectre_v1 command line option if necessary.
What about nobarrier_nospec (or similar) instead of nospectre_v1 command line? We are not disabling all the v1 mitigations, the masking part will remain unchanged. Diana