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=-8.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, T_DKIMWL_WL_MED,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 E9995C28CF6 for ; Fri, 3 Aug 2018 09:42:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9BD772173F for ; Fri, 3 Aug 2018 09:42:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="A7dPWiYb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9BD772173F Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.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 S1732520AbeHCLiZ (ORCPT ); Fri, 3 Aug 2018 07:38:25 -0400 Received: from mail-pl0-f68.google.com ([209.85.160.68]:36724 "EHLO mail-pl0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732292AbeHCLiY (ORCPT ); Fri, 3 Aug 2018 07:38:24 -0400 Received: by mail-pl0-f68.google.com with SMTP id e11-v6so2349910plb.3 for ; Fri, 03 Aug 2018 02:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tYCS5wD6vAtxWT95Bpgkjd+Us7bJHFzRkwkufQg4uGQ=; b=A7dPWiYbD56fAtxLzC3IjZMbfOLKHJM6UHF7tIxKGuhi/Xj5nMp/9XWf7f+KaOJHB0 KTD7WbgfdN1pJguLQlXz+OpgQSuvNwNpaXjEXF5Vx2ntsz4rtZCh5+DceZx8zAf72zad slmBGob2z14IobF6ad5PbCkQnLFuyjcnm/d2HiNegIylVdMGY3FIDFlFBPDWK5CoRLJW 0tkb6TAy5S5FGAL14ig2Te/qIuGCvncYckQEtWCxQneXOXP3S3BN0SqqV8+DXtwardwn 55qeK6EmgDmYPklzJhCxLI2LxEn1KxagHgU59Ba37rwMqsy0pnuCU3qxGmPwR5n/LoaR uxHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tYCS5wD6vAtxWT95Bpgkjd+Us7bJHFzRkwkufQg4uGQ=; b=J4LSaZs4slu72wK7HCzfB7HJNQ3PyVc2KTT+0gT+Vl0ZpEKTujsH6IJXS9DGsiE5Ki /4TrTxyo98P3VivkM2NREQnYYk/BTe1dcfLQU4Shdq9VYx3LNBIlZiUxf0ayJcule5W8 vNCc18bjWEQfAjvTfxWD4Iec951dQN1pKuFp2mCe3rYcVpRvMmAUZ4Qty89vZxnvOqZ4 cQZal88NpJbjV9B+Fu60o7/NTdSxszuwSwncduqndzrEgAk5+/1FZ9omSMFkoe3+WzVd SsIUwt3BhSj52y/uUkuVA16oM4rCMaugvwhdIeJ7wSm0yWl0D3Pl83GPlNAfzDazVTq7 QZgA== X-Gm-Message-State: AOUpUlGWN/zWvJ0djbtnwJNkhwfkvM8XpV2/ZCRxg64JEjrS+4GZ/9ap csCopeHv/OSXkTvz67WTXGm+6HCu5B9I5oIinkRCFQ== X-Google-Smtp-Source: AAOMgpdjI5mMdwC4CxAsKS7O2R8HcKUOrvYl14nmKC21/3PEoZo+ZrF/5HLo/HRbOUe81/y/r9XyF5zCbvltt5lz2wM= X-Received: by 2002:a17:902:d710:: with SMTP id w16-v6mr2849493ply.93.1533289373008; Fri, 03 Aug 2018 02:42:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:ac14:0:0:0:0 with HTTP; Fri, 3 Aug 2018 02:42:32 -0700 (PDT) In-Reply-To: <20180803092312.GA17798@arm.com> References: <20180628105057.GA26019@e103592.cambridge.arm.com> <20180629110709.GA17859@arm.com> <20180703173608.GF27243@arm.com> <20180801163538.GA10800@arm.com> <20180803092312.GA17798@arm.com> From: Dmitry Vyukov Date: Fri, 3 Aug 2018 11:42:32 +0200 Message-ID: Subject: Re: [PATCH v4 00/17] khwasan: kernel hardware assisted address sanitizer To: Will Deacon Cc: Andrey Konovalov , Andrew Morton , Catalin Marinas , Dave Martin , Andrey Ryabinin , Alexander Potapenko , Christoph Lameter , 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 3, 2018 at 11:23 AM, Will Deacon wrote: > On Wed, Aug 01, 2018 at 06:52:09PM +0200, Dmitry Vyukov wrote: >> On Wed, Aug 1, 2018 at 6:35 PM, Will Deacon wrote: >> > Thanks for tracking these cases down and going through each of them. The >> > obvious follow-up question is: how do we ensure that we keep on top of >> > this in mainline? Are you going to repeat your experiment at every kernel >> > release or every -rc or something else? I really can't see how we can >> > maintain this in the long run, especially given that the coverage we have >> > is only dynamic -- do you have an idea of how much coverage you're actually >> > getting for, say, a defconfig+modules build? >> > >> > I'd really like to enable pointer tagging in the kernel, I'm just still >> > failing to see how we can do it in a controlled manner where we can reason >> > about the semantic changes using something other than a best-effort, >> > case-by-case basis which is likely to be fragile and error-prone. >> > Unfortunately, if that's all we have, then this gets relegated to a >> > debug feature, which sort of defeats the point in my opinion. >> >> Well, in some cases there is no other way as resorting to dynamic testing. >> How do we ensure that kernel does not dereference NULL pointers, does >> not access objects after free or out of bounds? Nohow. And, yes, it's >> constant maintenance burden resolved via dynamic testing. > > ... and the advantage of NULL pointer issues is that you're likely to see > them as a synchronous exception at runtime, regardless of architecture and > regardless of Kconfig options. With pointer tagging, that's certainly not > the case, and so I don't think we can just treat issues there like we do for > NULL pointers. Well, let's take use-after-frees, out-of-bounds, info leaks, data races is a good example, deadlocks and just logical bugs... > If you want to enable khwasan in "production" and since enabling it > could potentially change the behaviour of existing code paths, the > run-time validation space doubles as we'd need to get the same code > coverage with and without the feature being enabled. This is true for just any change in configs, sysctls or just a different workload. Any of this can enable new code, exiting code working differently, or just working with data in new states. And we have tens of thousands of bugs, so blindly deploying anything new to production without proper testing is a bad idea. It's not specific to HWASAN in any way. And when you enable HWASAN you actually do mean to retest everything as hard as possible. And in the end we do not seem to have any action points here, right?