Re: [RFC PATCH] powerpc/fsl: Add barrier_nospec implementation for NXP PowerPC Book E

On 5/31/2018 5:21 PM, Michael Ellerman wrote:=0A=

Scott Wood [off-list ref] writes:=0A=

quoted

On Tue, 2018-05-29 at 15:22 +0000, Diana Madalina Craciun wrote:=0A=

quoted

On 05/22/2018 11:31 PM, Scott Wood wrote:=0A=

quoted

Should there be a way for the user to choose not to enable this (editi=

ng=0A=

quoted

quoted

quoted

the=0A=
device tree doesn't count), for a use case that is not sufficiently=0A=
security=0A=
sensitive to justify the performance loss?  What is the performance im=

pact=0A=

quoted

quoted

quoted

of=0A=
this patch?=0A=

My reason was that on the other architectures Spectre variant 1=0A=
mitigations are not disabled either. But I think that it might be a goo=

d=0A=

quoted

quoted

idea to add a bootarg parameter to disable the barrier.=0A=

Is there a specific policy reason why they allow spectre v2 to be disabl=

ed but=0A=

quoted

not v1,=0A=

No.=0A=
=0A=

quoted

or just a matter of not having a mechanism to disable it,=0A=

Yes and no. Some of the v1 mitigation is done via masking which can't be=

=0A=

easily patched. eg. array_index_nospec()=0A=
=0A=

quoted

or the parts which could practically be disabled not impacting=0A=
performance much?=0A=

That's the mean reason AIUI.=0A=
=0A=
We can add a nospectre_v1 command line option if necessary.=0A=

=0A=
What about nobarrier_nospec (or similar) instead of nospectre_v1 command=0A=
line? We are not disabling all the v1 mitigations, the masking part will=0A=
remain unchanged.=0A=
=0A=
Diana=0A=
=0A=
=0A=