• Peter Maydell's avatar
    arm64: fault: Don't leak data in ESR context for user fault on kernel VA · cc198460
    Peter Maydell authored
    If userspace faults on a kernel address, handing them the raw ESR
    value on the sigframe as part of the delivered signal can leak data
    useful to attackers who are using information about the underlying hardware
    fault type (e.g. translation vs permission) as a mechanism to defeat KASLR.
    However there are also legitimate uses for the information provided
    in the ESR -- notably the GCC and LLVM sanitizers use this to report
    whether wild pointer accesses by the application are reads or writes
    (since a wild write is a more serious bug than a wild read), so we
    don't want to drop the ESR information entirely.
    For faulting addresses in the kernel, sanitize the ESR. We choose
    to present userspace with the illusion that there is nothing mapped
    in the kernel's part of the address space at all, by reporting all
    faults as level 0 translation faults taken to EL1.
    These fields are safe to pass through to userspace as they depend
    only on the instruction that userspace used to provoke the fault:
     EC IL (always)
     ISV CM WNR (for all data aborts)
    All the other fields in ESR except DFSC are architecturally RES0
    for an L0 translation fault taken to EL1, so can be zeroed out
    without confusing userspace.
    The illusion is not entirely perfect, as there is a tiny wrinkle
    where we will report an alignment fault that was not due to the memory
    type (for instance a LDREX to an unaligned address) as a translation
    fault, whereas if you do this on real unmapped memory the alignment
    fault takes precedence. This is not likely to trip anybody up in
    practice, as the only users we know of for the ESR information who
    care about the behaviour for kernel addresses only really want to
    know about the WnR bit.
    Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
    Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>