[llvm-dev] [compiler-rt] Use of ESR context in AArch64 sigframe

[Peter Maydell via llvm-dev]

On 9 March 2018 at 19:29, Evgenii Stepanov <eugeni.stepanov at gmail.com> wrote:
> On Thu, Mar 8, 2018 at 9:11 AM, Will Deacon <will.deacon at arm.com> wrote:
>> It's also worth noting that the WnR bit needs special treatment for things
>> like atomic instructions and cache maintenance instructions which currently
>> appears to be missing. Would it be to bad to look at si_addr to spot kernel
>> addresses and handle them specially?
>
> We use this for preliminary classification of bugs, on the assumption
> that bad writes are scarier than bad reads. We don't care about
> si_addr permissions, what matters is the type of access requested by
> the faulting instruction, i.e. PC at the time of the fault. Worst
> case, we could disassemble the instruction to find out if its a read
> or a write, and on arm64 it is not even that hard.

...but it's a bit irritating to do that when the hardware
provides that information to the kernel and up til now
the kernel has been providing that information to userspace.
The disassemble-the-insn approach also forces you into
continuous updates to keep up to date with new load and store
instructions that are added in new architecture revisions
(for instance the v8.1 limited-ordering load/stores and
the SVE extension loads and stores).

Write-not-Read information is useful, aarch32 signal handlers
provide it, this feature went into the aarch64 kernel specifically
to provide that WnR info, so I'd really prefer it if we keep it.
Mask out the bad stuff if it's in kernel space, sure, but I don't
see the reason to throw the baby out with the bathwater here.
>From userspace's point of view, a fault for a read from the top
half of memory is no different from a fault for a read from
somewhere that doesn't have anything mapped at all, so it's
kind of weird for them to behave differently.

thanks
-- PMM