Change Details

I don't see any measurable slowdown for buildworld on Cortex-A15. MFC after: 2 weeks ------------------------ Out of records: There is still too much noise and inconsistent information on air. Mainly: - Why is branch predictor flush necessary only for prefetch translation/permission faults? By theory, it should be done for each user to system transition. It's unclear if this 'otimalization' was selected by ARM by analyzis of actual Linux code or if is determined by real branch predictor implementation for affected cores. - The Arm Trusted Firmware Security Advisory TFV 6 https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Security-Advisory-TFV-6 notes: "Note that the BPIALL instruction is not effective in invalidating the branch predictor on Cortex-A15. For that CPU, set ACTLR[0] to 1 during early processor initialisation, and invalidate the branch predictor by performing an ICIALLU instruction." but ARM TRM for Cortex-A15 declares this: Branch predictor requires flushing on: • enabling or disabling the MMU • writing new data to instruction locations • writing new mappings to the translation tables. • any change to the TTBR0, TTBR1, or TTBCR registers without a corresponding change to the FCSE ProcessID or ContextID. These two information are in direct conflict, I think. Anyway, Linux have similar patch, designed by ARM employees, so I cannot do much more that trust them.

Similarly as we already do for arm64, for mitigation is necessary to flush branch predictor when we: - do task switch - receive prefetch abort on non-userspace address The user can disable this mitigation by setting 'machdep.disable_bp_hardening' sysctl variable, or it can check actual system status by reading 'machdep.spectre_v2_safe' The situation is complicated by fact that: - for Cortex-A8, the BPIALL instruction is effectively NOP until the IBE bit in ACTLR is set. - for Cortex-A15, the BPIALL is always NOP. The branch predictor can be only flushed by doing ICIALLU with special bit (Enable invalidates of BTB) set in ACTLR. Since access to the ACTLR register is locked to secure monitor/firmware on most boards, they will also need update of firmware / U-boot. In worst case, when secure monitor is on-chip ROM (e.g. PandaBoard), the board is unfixable. MFC after: 2 weeks ------------------------ Out of records: There is still too much noise and inconsistent information on air. Mainly: - Why is branch predictor flush necessary only for prefetch translation/permission faults? By theory, it should be done for each user to system transition. It's unclear if this 'otimalization' was selected by ARM by analyzis of actual Linux code or if is determined by real branch predictor implementation for affected cores. - The Arm Trusted Firmware Security Advisory TFV 6 https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Security-Advisory-TFV-6 notes: "Note that the BPIALL instruction is not effective in invalidating the branch predictor on Cortex-A15. For that CPU, set ACTLR[0] to 1 during early processor initialisation, and invalidate the branch predictor by performing an ICIALLU instruction." but ARM TRM for Cortex-A15 declares this: Branch predictor requires flushing on: • enabling or disabling the MMU • writing new data to instruction locations • writing new mappings to the translation tables. • any change to the TTBR0, TTBR1, or TTBCR registers without a corresponding change to the FCSE ProcessID or ContextID. These two information are in direct conflict, I think. Anyway, Linux have similar patch, designed by ARM employees, so I cannot do much more that trust them.

I don't see any measurable slowdown for buildworld on Cortex-A15Similarly as we already do for arm64, for mitigation is necessary to flush branch predictor when we: - do task switch - receive prefetch abort on non-userspace address The user can disable this mitigation by setting 'machdep.disable_bp_hardening' sysctl variable, or it can check actual system status by reading 'machdep.spectre_v2_safe' The situation is complicated by fact that: - for Cortex-A8, the BPIALL instruction is effectively NOP until the IBE bit in ACTLR is set. - for Cortex-A15, the BPIALL is always NOP. The branch predictor can be only flushed by doing ICIALLU with special bit (Enable invalidates of BTB) set in ACTLR. Since access to the ACTLR register is locked to secure monitor/firmware on most boards, they will also need update of firmware / U-boot. In worst case, when secure monitor is on-chip ROM (e.g. PandaBoard), the board is unfixable. MFC after: 2 weeks ------------------------ Out of records: There is still too much noise and inconsistent information on air. Mainly: - Why is branch predictor flush necessary only for prefetch translation/permission faults? By theory, it should be done for each user to system transition. It's unclear if this 'otimalization' was selected by ARM by analyzis of actual Linux code or if is determined by real branch predictor implementation for affected cores. - The Arm Trusted Firmware Security Advisory TFV 6 https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Security-Advisory-TFV-6 notes: "Note that the BPIALL instruction is not effective in invalidating the branch predictor on Cortex-A15. For that CPU, set ACTLR[0] to 1 during early processor initialisation, and invalidate the branch predictor by performing an ICIALLU instruction." but ARM TRM for Cortex-A15 declares this: Branch predictor requires flushing on: • enabling or disabling the MMU • writing new data to instruction locations • writing new mappings to the translation tables. • any change to the TTBR0, TTBR1, or TTBCR registers without a corresponding change to the FCSE ProcessID or ContextID. These two information are in direct conflict, I think. Anyway, Linux have similar patch, designed by ARM employees, so I cannot do much more that trust them.