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=-3.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 79FDDC433DB for ; Tue, 19 Jan 2021 13:02:09 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 049642312E for ; Tue, 19 Jan 2021 13:02:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 049642312E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=HUCK9OLa+FHF51eaTjN5QH8LEi91KRRR2KxVZNGqjA4=; b=LLJQ4D8kvH5K9ZSe436trpcUA 0HJYevmg8iFpPc3jOTQezZZsY/G2zPdIv1iWv+geDRpLnTDeSIrL+ZAt6ZvnpZX5aLxV/UvHy65UX sJdnklqXKRQei+zWZHlceGcxxuu0DHd+Wn1O+bhrFMxrPt7vKJeDZxBKC7vJUS0rHLw/wQAjl/Bjs YlOAqdfElGQH4QZmPvti7JI9bMruS2orHs7QPWctPjRbjrBKEHfhNGfJ8Xn757z5oPQNMUtDZR04R miCKrtfYhAyLqbLGBXTDL7QYnc3PHbCyjAyL1YObAuHpZnl8Rr3Xyo13etgSXVPCKF6H4r+36dBqJ 0RjeNpOnw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l1qcj-0004MB-4J; Tue, 19 Jan 2021 13:00:41 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l1qcc-0004KX-Op for linux-arm-kernel@lists.infradead.org; Tue, 19 Jan 2021 13:00:38 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D35BE113E; Tue, 19 Jan 2021 05:00:27 -0800 (PST) Received: from C02TD0UTHF1T.local (unknown [10.57.41.13]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DBC7F3F719; Tue, 19 Jan 2021 05:00:25 -0800 (PST) Date: Tue, 19 Jan 2021 13:00:10 +0000 From: Mark Rutland To: 'Dmitry Vyukov' via syzkaller Subject: Re: Arm + KASAN + syzbot Message-ID: <20210119130010.GA2338@C02TD0UTHF1T.local> References: <20210119100355.GA21435@C02TD0UTHF1T.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210119_080034_959413_AE87D097 X-CRM114-Status: GOOD ( 30.41 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Arnd Bergmann , Linus Walleij , Russell King - ARM Linux , kasan-dev , Krzysztof Kozlowski , Hailong Liu , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jan 19, 2021 at 11:34:33AM +0100, 'Dmitry Vyukov' via syzkaller wrote: > On Tue, Jan 19, 2021 at 11:04 AM Mark Rutland wrote: > > On Mon, Jan 18, 2021 at 05:31:36PM +0100, 'Dmitry Vyukov' via syzkaller wrote: > > It might be best to use `-machine virt` here instead; that way QEMU > > won't need to emulate any of the real vexpress HW, and the kernel won't > > need to waste any time poking it. > > Hi Mark, > > The whole point of setting up an Arm instance is getting as much > coverage we can't get on x86_64 instances as possible. The instance > will use qemu emulation (extremely slow) and limited capacity. > I see some drivers and associated hardware support as one of the main > such areas. That's why I tried to use vexpress-a15. And it boots > without KASAN, so presumably it can be used in general. Fair enough. I had assumed that your first aim would to cover the arch code shared across all arm platforms, to flush out any big/common problems first, for which the virt platform is a good start, and has worked quite well for arm64. [...] > > > 3. CONFIG_KCOV does not seem to fully work. > > > It seems to work except for when the kernel crashes, and that's the > > > most interesting scenario for us. When the kernel crashes for other > > > reasons, crash handlers re-crashe in KCOV making all crashes > > > unactionable and indistinguishable. > > > Here are some samples (search for __sanitizer_cov_trace): > > > https://gist.githubusercontent.com/dvyukov/c8a7ff1c00a5223c5143fd90073f5bc4/raw/c0f4ac7fd7faad7253843584fed8620ac6006338/gistfile1.txt > > > > Most of those are all small offsets from 0, which suggests an offset is > > being added to a NULL pointer somewhere, which I suspect means > > task_struct::kcov_area is NULL. We could hack-in a check for that, and > > see if that's the case (though I can't see how from a quick scan of the > > kcov code). > > My first guess would be is that current itself if NULL. I think if that were to happen (which'd imply corruption of thread_info) the fault handling and logging would also blow up, so I suspect this isn't the case. Do you have a reelvant vmlinux to hand? With that we could figure out which access is faulting, how the address is being generated, and where the bogus address is coming from, without having to guess. :) > Accesses to current->kcov* are well tested on other arches, including > using KCOV in interrupts, etc. While that's generally true, architectures differ in a number of ways that can affect this (e.g. how the vmalloc area is faulted, what precisely is preemptible/interruptible), and we had to make preparatory changes to make KCOV work on arm even though it was working perfectly fine on arm64 and x86_64, e.g. * c9484b986ef03492 ("kcov: ensure irq code sees a valid area") * dc55daff9040a90a ("kcov: prefault the kcov_area") * 0ed557aa813922f6 ("sched/core / kcov: avoid kcov_area during task switch") ... so I don't think we can rule out the possibility of a latent issue here, even if we haven't triggered it elsewhere. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel