From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 71EB7C6778C for ; Tue, 3 Jul 2018 17:35:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 340AC23C52 for ; Tue, 3 Jul 2018 17:35:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 340AC23C52 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934363AbeGCRfe (ORCPT ); Tue, 3 Jul 2018 13:35:34 -0400 Received: from foss.arm.com ([217.140.101.70]:53440 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934296AbeGCRfa (ORCPT ); Tue, 3 Jul 2018 13:35:30 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7F5017A9; Tue, 3 Jul 2018 10:35:29 -0700 (PDT) Received: from edgewater-inn.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 4F3C13F5BA; Tue, 3 Jul 2018 10:35:29 -0700 (PDT) Received: by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000) id F3C241AE55A7; Tue, 3 Jul 2018 18:36:08 +0100 (BST) Date: Tue, 3 Jul 2018 18:36:08 +0100 From: Will Deacon 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 Subject: Re: [PATCH v4 00/17] khwasan: kernel hardware assisted address sanitizer Message-ID: <20180703173608.GF27243@arm.com> References: <20180628105057.GA26019@e103592.cambridge.arm.com> <20180629110709.GA17859@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 29, 2018 at 06:36:10PM +0200, Andrey Konovalov wrote: > On Fri, Jun 29, 2018 at 1:07 PM, Will Deacon 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. Hmm, but elsewhere in this thread, Evgenii is motivating the need for this patch set precisely because the lower overhead means it's suitable for "near-production" use. So I don't think writing this off as a debugging feature is the right approach, and we instead need to put effort into analysing the impact of address tags on the kernel as a whole. Playing whack-a-mole with subtle tag issues sounds like the worst possible outcome for the long-term. Will