[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180629110709.GA17859@arm.com>
Date: Fri, 29 Jun 2018 12:07:10 +0100
From: Will Deacon <will.deacon@....com>
To: Andrey Konovalov <andreyknvl@...gle.com>
Cc: Dave Martin <Dave.Martin@....com>,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
Alexander Potapenko <glider@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Catalin Marinas <catalin.marinas@....com>,
Christoph Lameter <cl@...ux.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Mark Rutland <mark.rutland@....com>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Marc Zyngier <marc.zyngier@....com>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
"Eric W . Biederman" <ebiederm@...ssion.com>,
Ingo Molnar <mingo@...nel.org>,
Paul Lawrence <paullawrence@...gle.com>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Arnd Bergmann <arnd@...db.de>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Kate Stewart <kstewart@...uxfoundation.org>,
Mike Rapoport <rppt@...ux.vnet.ibm.com>,
kasan-dev <kasan-dev@...glegroups.com>,
linux-doc@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
linux-sparse@...r.kernel.org,
Linux Memory Management List <linux-mm@...ck.org>,
Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
Chintan Pandya <cpandya@...eaurora.org>,
Jacob Bramley <Jacob.Bramley@....com>,
Jann Horn <jannh@...gle.com>,
Ruben Ayrapetyan <Ruben.Ayrapetyan@....com>,
Lee Smith <Lee.Smith@....com>,
Kostya Serebryany <kcc@...gle.com>,
Mark Brand <markbrand@...gle.com>,
Ramana Radhakrishnan <Ramana.Radhakrishnan@....com>,
Evgeniy Stepanov <eugenis@...gle.com>
Subject: Re: [PATCH v4 00/17] khwasan: kernel hardware assisted address
sanitizer
On Thu, Jun 28, 2018 at 08:56:41PM +0200, Andrey Konovalov wrote:
> On Thu, Jun 28, 2018 at 12:51 PM, Dave Martin <Dave.Martin@....com> wrote:
> > On Tue, Jun 26, 2018 at 03:15:10PM +0200, Andrey Konovalov wrote:
> >> 1. By using the Top Byte Ignore arm64 CPU feature, we can store pointer
> >> tags in the top byte of each kernel pointer.
> >
> > [...]
> >
> > This is a change from the current situation, so the kernel may be
> > making implicit assumptions about the top byte of kernel addresses.
> >
> > Randomising the top bits may cause things like address conversions and
> > pointer arithmetic to break.
> >
> > For example, (q - p) will not produce the expected result if q and p
> > have different tags.
>
> If q and p have different tags, that means they come from different
> allocations. I don't think it would make sense to calculate pointer
> difference in this case.
It might not seen sensible, but we could still be relying on this in the
kernel and so this change would introduce a regression. I think we need
a way to identify such pointer usage before these patches can seriously be
considered for mainline inclusion. For example use of '>' and '<' to
compare pointers in an rbtree could be affected by the introduction of
tags.
Will
Powered by blists - more mailing lists