[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAeHK+wHd8B2nhat-Z2Y2=s4NVobPG7vjr2CynjFhqPTwQRepQ@mail.gmail.com>
Date: Fri, 29 Jun 2018 18:36:10 +0200
From: Andrey Konovalov <andreyknvl@...gle.com>
To: Will Deacon <will.deacon@....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 Fri, Jun 29, 2018 at 1:07 PM, Will Deacon <will.deacon@....com> wrote:
> 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.
Another point that I have here is that KHWASAN is a debugging tool not
meant to be used in production. We're not trying to change the ABI or
something like that (referring to the other HWASAN patchset). We can
fix up the non obvious places where untagging is needed in a case by
case basis with additional patches when testing reveals it.
Powered by blists - more mailing lists