From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f69.google.com (mail-oi0-f69.google.com [209.85.218.69]) by kanga.kvack.org (Postfix) with ESMTP id 29BEC6B0005 for ; Fri, 29 Jun 2018 07:06:34 -0400 (EDT) Received: by mail-oi0-f69.google.com with SMTP id x18-v6so1886622oie.7 for ; Fri, 29 Jun 2018 04:06:34 -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 u63-v6si3003555oib.328.2018.06.29.04.06.32 for ; Fri, 29 Jun 2018 04:06:33 -0700 (PDT) Date: Fri, 29 Jun 2018 12:07:10 +0100 From: Will Deacon Subject: Re: [PATCH v4 00/17] khwasan: kernel hardware assisted address sanitizer Message-ID: <20180629110709.GA17859@arm.com> References: <20180628105057.GA26019@e103592.cambridge.arm.com> 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: Dave Martin , Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Catalin Marinas , 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 , linux-doc@vger.kernel.org, LKML , Linux ARM , linux-sparse@vger.kernel.org, Linux Memory Management List , Linux Kbuild mailing list , Chintan Pandya , Jacob Bramley , Jann Horn , Ruben Ayrapetyan , Lee Smith , Kostya Serebryany , Mark Brand , Ramana Radhakrishnan , Evgeniy Stepanov On Thu, Jun 28, 2018 at 08:56:41PM +0200, Andrey Konovalov wrote: > On Thu, Jun 28, 2018 at 12:51 PM, Dave Martin 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