[PATCH 0/3] ARM: fix hash_name() and branch predictor issues

Xie Yuanbin xieyuanbin1 at huawei.com
Mon Dec 8 18:15:19 PST 2025


On Mon, 8 Dec 2025 15:59:49 +0000, Russell King wrote:
> However, there is a user accessible page above TASK_SIZE, that is the
> vectors page which can have userspace helpers in. Userspace can read
> from this page, and thus can perform unaligned loads to this page.

Thanks for your reply.

This is a key point, I think. This means that triggering an kernel
address's do_alignment() from user-mode is possible, and it's a normal
situation, not even a fault. And I also found that alignment_get_thumb()
and alignment_get_arm() might cause a fault, which will make things even
more complicated if we still keep harden_branch_predictor() inside
__do_user_fault().

In conclusion, this(these patches) should be the best solution; I can't
think of a better way.

> The system behaviour of unaligned loads has been configurable, ARMv4,
> for example, had the ability to check for alignment faults and raise
> this exception. If that was disabled, then unaligned loads would
> load the equivalent 32-bit aligned address and rotate the data in
> the register. Compilers knew about this, and would code for it,
> which made it ABI. Later compilers stopped using that which cut down
> on the unaligned loads that userspace issued. Modern CPUs (ARMv7)
> tend to behave "sanely" in that unaligned loads are generally
> supported in hardware.

Yes, I have a general understanding of this. Anyway, thanks for your
reply.



More information about the linux-arm-kernel mailing list