[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180628105057.GA26019@e103592.cambridge.arm.com>
Date: Thu, 28 Jun 2018 11:51:06 +0100
From: Dave Martin <Dave.Martin@....com>
To: Andrey Konovalov <andreyknvl@...gle.com>
Cc: Andrey Ryabinin <aryabinin@...tuozzo.com>,
Alexander Potapenko <glider@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....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@...glegroups.com, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-sparse@...r.kernel.org, linux-mm@...ck.org,
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 Tue, Jun 26, 2018 at 03:15:10PM +0200, Andrey Konovalov wrote:
> This patchset adds a new mode to KASAN [1], which is called KHWASAN
> (Kernel HardWare assisted Address SANitizer).
>
> The plan is to implement HWASan [2] for the kernel with the incentive,
> that it's going to have comparable to KASAN performance, but in the same
> time consume much less memory, trading that off for somewhat imprecise
> bug detection and being supported only for arm64.
>
> The overall idea of the approach used by KHWASAN is the following:
>
> 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.
Conversions, such as between pointer and pfn, may also go wrong if not
appropriately masked.
There are also potential pointer comparison and aliasing issues if
the tag bits are ever stripped or modified.
What was your approach to tracking down all the points in the code
where we have a potential issue?
(I haven't dug through the series in detail yet, so this may be
answered somewhere already...)
Cheers
---Dave
Powered by blists - more mailing lists