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

[Diana Madalina Craciun <diana.craciun@nxp.com>]

On 5/31/2018 5:21 PM, Michael Ellerman wrote:=0A=
> Scott Wood <oss@buserror.net> writes:=0A=
>> On Tue, 2018-05-29 at 15:22 +0000, Diana Madalina Craciun wrote:=0A=
>>> On 05/22/2018 11:31 PM, Scott Wood wrote:=0A=
>>>> Should there be a way for the user to choose not to enable this (editi=
ng=0A=
>>>> 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=
>>>> 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=
>>> 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=
>> not v1,=0A=
> No.=0A=
>=0A=
>> 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=
>> 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=