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.2 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 6E352FC6182 for ; Fri, 14 Sep 2018 15:28:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3080B20882 for ; Fri, 14 Sep 2018 15:28:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3080B20882 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 S1728285AbeINUnK (ORCPT ); Fri, 14 Sep 2018 16:43:10 -0400 Received: from foss.arm.com ([217.140.101.70]:35498 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726902AbeINUnJ (ORCPT ); Fri, 14 Sep 2018 16:43:09 -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 C282580D; Fri, 14 Sep 2018 08:28:08 -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 91CD23F557; Fri, 14 Sep 2018 08:28:08 -0700 (PDT) Received: by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000) id 2BD581AE2F82; Fri, 14 Sep 2018 16:28:26 +0100 (BST) Date: Fri, 14 Sep 2018 16:28:26 +0100 From: Will Deacon To: Andrey Konovalov Cc: Andrew Morton , Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Catalin Marinas , Christoph Lameter , Mark Rutland , Nick Desaulniers , Marc Zyngier , Dave Martin , 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 , Kostya Serebryany , Evgeniy Stepanov , Lee Smith , Ramana Radhakrishnan , Jacob Bramley , Ruben Ayrapetyan , Jann Horn , Mark Brand , Chintan Pandya , Vishwath Mohan Subject: Re: [PATCH v6 00/18] khwasan: kernel hardware assisted address sanitizer Message-ID: <20180914152825.GC6236@arm.com> References: <20180905141032.b1ddaab53d1b2b3bada95415@linux-foundation.org> <20180906100543.GI3592@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 Thu, Sep 06, 2018 at 01:06:23PM +0200, Andrey Konovalov wrote: > On Thu, Sep 6, 2018 at 12:05 PM, Will Deacon wrote: > > On Wed, Sep 05, 2018 at 02:10:32PM -0700, Andrew Morton wrote: > >> On Wed, 29 Aug 2018 13:35:04 +0200 Andrey Konovalov wrote: > >> > >> > This patchset adds a new mode to KASAN [1], which is called KHWASAN > >> > (Kernel HardWare assisted Address SANitizer). > >> > >> We're at v6 and there are no reviewed-by's or acked-by's to be seen. > >> Is that a fair commentary on what has been happening, or have people > >> been remiss in sending and gathering such things? > > > > I still have concerns about the consequences of merging this as anything > > other than a debug option [1]. Unfortunately, merging it as a debug option > > defeats the whole point, so I think we need to spend more effort on developing > > tools that can help us to find and fix the subtle bugs which will arise from > > enabling tagged pointers in the kernel. > > I totally don't mind calling it a debug option. Do I need to somehow > specify it somewhere? Ok, sorry, I completely misunderstood you earlier on then! For some reason I thought you wanted this on by default. In which case, I'm ok with the overall idea as long as we make the caveats clear in the Kconfig text. In particular, that enabling this option may introduce problems relating to pointer casting and comparison, but can offer better coverage and lower memory consumption than a fully software-based KASAN solution. Will