From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot0-f199.google.com (mail-ot0-f199.google.com [74.125.82.199]) by kanga.kvack.org (Postfix) with ESMTP id 785206B000A for ; Thu, 28 Jun 2018 06:51:22 -0400 (EDT) Received: by mail-ot0-f199.google.com with SMTP id w15-v6so3227120otk.12 for ; Thu, 28 Jun 2018 03:51:22 -0700 (PDT) Received: from foss.arm.com (usa-sjc-mx-foss1.foss.arm.com. [217.140.101.70]) by mx.google.com with ESMTP id w84-v6si761637oie.274.2018.06.28.03.51.21 for ; Thu, 28 Jun 2018 03:51:21 -0700 (PDT) Date: Thu, 28 Jun 2018 11:51:06 +0100 From: Dave Martin Subject: Re: [PATCH v4 00/17] khwasan: kernel hardware assisted address sanitizer Message-ID: <20180628105057.GA26019@e103592.cambridge.arm.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Andrey Konovalov Cc: Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Catalin Marinas , Will Deacon , Christoph Lameter , Andrew Morton , Mark Rutland , Nick Desaulniers , Marc Zyngier , Ard Biesheuvel , "Eric W . Biederman" , Ingo Molnar , Paul Lawrence , Geert Uytterhoeven , Arnd Bergmann , "Kirill A . Shutemov" , Greg Kroah-Hartman , Kate Stewart , Mike Rapoport , kasan-dev@googlegroups.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sparse@vger.kernel.org, linux-mm@kvack.org, linux-kbuild@vger.kernel.org, Chintan Pandya , Jacob Bramley , Jann Horn , Ruben Ayrapetyan , Lee Smith , Kostya Serebryany , Mark Brand , Ramana Radhakrishnan , Evgeniy Stepanov 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