Andrey Ryabinin via llvm-dev
2018-Mar-07 15:39 UTC
[llvm-dev] [compiler-rt] Use of ESR context in AArch64 sigframe
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.> Many thanks, > > Will >
Evgenii Stepanov via llvm-dev
2018-Mar-07 19:40 UTC
[llvm-dev] [compiler-rt] Use of ESR context in AArch64 sigframe
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.
Maybe Matching Threads
- [compiler-rt] Use of ESR context in AArch64 sigframe
- [compiler-rt] Use of ESR context in AArch64 sigframe
- [compiler-rt] Use of ESR context in AArch64 sigframe
- [compiler-rt] Use of ESR context in AArch64 sigframe
- [compiler-rt] Use of ESR context in AArch64 sigframe