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 1E66AC43141 for ; Fri, 29 Jun 2018 11:04:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D5E9227CB8 for ; Fri, 29 Jun 2018 11:04:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D5E9227CB8 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 S933910AbeF2LEf (ORCPT ); Fri, 29 Jun 2018 07:04:35 -0400 Received: from foss.arm.com ([217.140.101.70]:59654 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932078AbeF2LEb (ORCPT ); Fri, 29 Jun 2018 07:04:31 -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 9570018A; Fri, 29 Jun 2018 04:04:30 -0700 (PDT) Received: from e103592.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 E02B73F266; Fri, 29 Jun 2018 04:04:24 -0700 (PDT) Date: Fri, 29 Jun 2018 12:04:22 +0100 From: Dave Martin To: Andrey Konovalov Cc: Mark Rutland , Kate Stewart , linux-doc@vger.kernel.org, Catalin Marinas , Will Deacon , Paul Lawrence , Linux Memory Management List , Alexander Potapenko , Chintan Pandya , Christoph Lameter , Ingo Molnar , Jacob Bramley , Jann Horn , Mark Brand , kasan-dev , linux-sparse@vger.kernel.org, Geert Uytterhoeven , Linux ARM , Andrey Ryabinin , Evgeniy Stepanov , Arnd Bergmann , Linux Kbuild mailing list , Marc Zyngier , Ramana Radhakrishnan , Ruben Ayrapetyan , Mike Rapoport , Dmitry Vyukov , Kostya Serebryany , Ard Biesheuvel , Greg Kroah-Hartman , Nick Desaulniers , LKML , "Eric W . Biederman" , Lee Smith , Andrew Morton , "Kirill A . Shutemov" Subject: Re: [PATCH v4 00/17] khwasan: kernel hardware assisted address sanitizer Message-ID: <20180629110419.GC26019@e103592.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: 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, 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's not strictly valid to subtract pointers from different allocations in C, but it's hard to prove statically that two pointers are guaranteed to point into the same allocation. It's likely that we're getting away with it in some places today. > > Conversions, such as between pointer and pfn, may also go wrong if not > > appropriately masked. > > > > There are also potential pointer comparison and aliasing issues if > > the tag bits are ever stripped or modified. > > > > > > 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. Can sparse be hacked to identify pointer subtractions where the pointers are cannot be statically proved to point into the same allocation? Maybe the number of hits for this wouldn't be outrageously high, though I expect there would be a fair number. Tracking pointers that have been cast to integer types is harder. Ideally we'd want to do that, to flag up potentially problematic masking and other similar hacks. Cheers ---Dave