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.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_NEOMUTT 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 A221DC43141 for ; Fri, 29 Jun 2018 10:14:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5719927B56 for ; Fri, 29 Jun 2018 10:14:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5719927B56 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 S1753489AbeF2KOr (ORCPT ); Fri, 29 Jun 2018 06:14:47 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:59200 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751901AbeF2KOo (ORCPT ); Fri, 29 Jun 2018 06:14:44 -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 BD2121529; Fri, 29 Jun 2018 03:14:43 -0700 (PDT) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 145AD3F266; Fri, 29 Jun 2018 03:14:37 -0700 (PDT) Date: Fri, 29 Jun 2018 11:14:35 +0100 From: Mark Rutland To: Andrey Konovalov Cc: Dave Martin , Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Catalin Marinas , Will Deacon , Christoph Lameter , Andrew Morton , 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: <20180629101435.263hujat2amnm3hi@lakrids.cambridge.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: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. [...] > > What was your approach to tracking down all the points in the code > > where we have a potential issue? > > I've been fuzzing the kernel built with KWHASAN with syzkaller. This > gives a decent coverage and I was able to find some places where > fixups were required this way. Right now the fuzzer is running without > issues. It doesn't prove that all such places are fixed, but I don't > know a better way to test this. While fuzzing shows that the kernel doesn't crash (and this is very important), it does not show that it exhibits the expected behaviour, and there could be a number of soft failures present. e.g. certain functions might just return an error code if a pointer has a tag other than 0xff (such that it looks like a kernel pointer) or 0x00 (such that it looks like a user pointer), and this might not result in a fatal error even though the behaviour is not what we require. Perhaps it's possible to compare the behaviour of a kernel making use of tags with one which does not, though I'm not sure at which level the comparison needs to be performed. Thanks, Mark.