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

[Evgenii Stepanov via llvm-dev]

On Wed, Mar 7, 2018 at 7:48 AM, Dmitry Vyukov <dvyukov at google.com> wrote:
> On Wed, Mar 7, 2018 at 4:39 PM, Andrey Ryabinin <aryabinin at virtuozzo.com> wrote:
>> On 03/06/2018 08:58 PM, Will Deacon wrote:
>>> Hi all,
>>>
>>> As part of some recent work to harden the Kernel Address Space Layout
>>> Randomisation (KASLR) implementation in arm64 Linux, I've proposed a
>>> patch for the kernel which omits the ESR context from the signal frame
>>> if the faulting virtual address is outside the range of addresses which
>>> can be mapped by userspace.
>>>
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2018-March/563837.html
>>>
>>> Looking around, it seems that AddressSanitizer is using this information
>>> in compiler-rt in order to distinguish the faulting access type between
>>> READ, WRITE or UNKNOWN. With this change, all attempted accesses to kernel
>>> memory from userspace will be reported as UNKNOWN.
>>>
>>> Is this likely to cause a problem?
>>
>> I guess this shouldn't be a bid deal.
>> AFAICS compiler-rt uses this information only in diagnostic message.
>
> +address-sanitizer mailing list
>
> Hi,
>
> These diagnostic messages are then parsed and analyzed, and access
> type is used at least during automatic security pre-assessment. Being
> capable to read arbitrary memory is different from being able to write
> arbitrary memory. Though, I don't know how we treat UNKNOWN. If it's
> the same as WRITE, then it's probably fine.

This would disable read/write detection for almost all wild pointer
dereferences, since they are more than likely to have a 1 in one of
the higher order bits. This is undesirable, but not the end of the
world. Is it possible to sanitize ESR instead of omitting it
altogether?

Also, your patch looks like it would disable ESR context for all
faults on tagged addresses, too. Since Linux unconditionally enables
TBI, it should be safe to zero out the MSB before the address check.