Comment 17 for bug 507416

Revision history for this message
Dave Martin (dave-martin-arm) wrote :

Re-opening the bug to discuss some new issues.

Both of these problems are effectively present in the previous Ubuntu releases on imx51, as well as lucid.

1) CONFIG_NEON=n doesn't actually disable the use of NEON instructions (I misinderstood things here). It should be straightforward to improve the situation here: for platforms with known problems, or when CONFIG_NEON=n, we can set the ASEDIS bit in the CP15 Coprocessor Access Control Register on boot. This disables the part of the NEON instruction space containing the instructions which can cause unaligned accesses to occur.

2) It appears that all unaligned accesses (not just NEON) can cause problems. This may apply to cached memory, but has not definitely been observed. However, the problem is observable for uncached memory. This means that memory-mapped drivers such as the framebuffer or media accelerators can provide userspace processes with a way to hit the bug using ordinary unaligned loads and stores.

The problem is that the kernel does not trap ordinary loads and stores on ARMv6 and above, because these processors support the unaligned access natively.

arch/arm/mm/alignment.c:
static int __init alignment_init(void)
{
        ...
        if (cpu_architecture() >= CPU_ARCH_ARMv6 && (cr_alignment & CR_U)) {
                cr_alignment &= ~CR_A;
                cr_no_alignment &= ~CR_A;
                set_cr(cr_alignment);
                ai_usermode = UM_FIXUP;
        }

In principle we could support the full faulting by modifying the if() condition, however there are two problems with this:
    a) there may be a performance impact, since more loads and stores will be emulated via the kernel
    b) some extra implementation is needed in arch/arm/mm/alignment.c:do_alignment_t32_to_handler() to recognise the 32-bit Thumb-2 load and store instructions (since all processors which have these instructions also have native unaligned access support); recognising these instructions is not implemented at present, which means that such instructions will either SIGILL, or spin as they are continuously refaulted.