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

Diana Madalina Craciun diana.craciun at nxp.com
Fri Jun 1 00:35:25 AEST 2018


On 5/31/2018 5:21 PM, Michael Ellerman wrote:
> Scott Wood <oss at 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




More information about the Linuxppc-dev mailing list