GNU Assembler Patches For Optimizing The Intel Jump Conditional Code Erratum

Re:GNU Assembler Patches For Optimizing The Intel Jump Condi... by cesarb on Thursday November 14, 2019 @09:09AM (#21535424)

ARM is no better. One of the most popular ARM boards (the Raspberry Pi) uses a core which is affected by an errata which also needs a workaround on the assembler/linker. I don't have my RPi with me at the moment, so I don't know the errata number (it's one of the two printed by the kernel during boot).

[ Parent | on HN ]

Re:GNU Assembler Patches For Optimizing The Intel Jump Condi... by yabadabadoes on Thursday November 14, 2019 @02:26PM (#21538498)

One errata on a broadcom(?) chip makes ARM no better than Intel? I think RPi has had to explain a few times why they choose problematic chips.

[ Parent | on HN ]

Re:GNU Assembler Patches For Optimizing The Intel Jump Condi... by cesarb on Thursday November 14, 2019 @02:43PM (#21538643)

The errata is not from Broadcom, it's on the Cortex-A53 core from ARM it uses. From a quick search, it's probably errata 843419 (see https://static.docs.arm.com/epm048406/200/Cortex-A53_MPCore_...), worked around by passing the --fix-cortex-a53-843419 parameter to the linker.

And like this Intel errata, it's instruction-address-dependent: one of the conditions to trigger it is when the relevant instruction is near the end of a 4K page. One workaround being "put the instruction somewhere else".

[ Parent | on HN ]

Re:GNU Assembler Patches For Optimizing The Intel Jump Condi... by yabadabadoes on Thursday November 14, 2019 @03:51PM (#21539258)

Well that is an ARM errata, but if I understand correctly it's basically if you drop caching in a way only a privileged thing like hypervisor is allowed to do so this workaround is in some specific code..

The initial reports and secrecy around the Intel issue makes it sound like they need to be mitigating all the time in normal modes.. But I guess it will take some time to see what is really going on.

[ Parent | on HN ]