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=-9.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 4891AC433DB for ; Thu, 11 Mar 2021 12:35:14 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 D368064FDF for ; Thu, 11 Mar 2021 12:35:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D368064FDF 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=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc: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=Pgk/9HDbjyEFE8hXgV7V+rJW8YjjecKSmaJAtFq1T8k=; b=JRTqbqKH/s2WL18LET8gQChnK R4GlvAgYBNY27OdksxvQK1euRsy95KsKrnzjjZG/6bGHrqEE7qaxJfJOOSXEE8dpIrgC1q9u+10Az 4I+gU5jcA3blqls8Co4fwj8MFwxPkUpLLKWXGlq+WpQMfq8KpNPc7W/EfnHfZWNA57s4TgHdZ5c4L AK551ePXhxOIKB5QGF+9OZYQrqQKPBS8sgVA4HXRgBYHzevnS7J9tlad/1ODx/Un34XCD0V7jOvNe fUAPp3VzMd8JMib+ovVaPbGRDWwPn/FW3+N82l14xfUlH/YD3pPwl5Lx0+dlkhpy1Esrwd6CArqQy h3coWrYAQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lKKVR-0096Q6-T1; Thu, 11 Mar 2021 12:33:34 +0000 Received: from foss.arm.com ([217.140.110.172]) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lKKVH-0096My-FN for linux-arm-kernel@lists.infradead.org; Thu, 11 Mar 2021 12:33:30 +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 6499A31B; Thu, 11 Mar 2021 04:33:20 -0800 (PST) Received: from C02TD0UTHF1T.local (unknown [10.57.54.221]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8C4EC3F793; Thu, 11 Mar 2021 04:33:18 -0800 (PST) Date: Thu, 11 Mar 2021 12:33:15 +0000 From: Mark Rutland To: Dmitry Vyukov Cc: maz@kernel.org, Will Deacon , Ard Biesheuvel , Linux ARM , Arnd Bergmann , syzkaller , LKML Subject: Re: arm64 syzbot instances Message-ID: <20210311123315.GF37303@C02TD0UTHF1T.local> References: 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-20210311_123324_717524_0207C92D X-CRM114-Status: GOOD ( 30.61 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Thu, Mar 11, 2021 at 12:38:21PM +0100, 'Dmitry Vyukov' via syzkaller wrote: > Hi arm64 maintainers, Hi Dmitry, > We now have some syzbot instances testing arm64 (woohoo!) using qemu > emulation. I wanted to write up the current status. Nice! > There are 3 instances, first uses KASAN: > https://syzkaller.appspot.com/upstream?manager=ci-qemu2-arm64 > second KASAN and 32-bit userspace test load (compat): > https://syzkaller.appspot.com/upstream?manager=ci-qemu2-arm64-compat > third uses MTE/KASAN_HWTAGS: > https://syzkaller.appspot.com/upstream?manager=ci-qemu2-arm64-mte > > Kernel configs: > https://github.com/google/syzkaller/blob/master/dashboard/config/linux/upstream-arm64-kasan.config > https://github.com/google/syzkaller/blob/master/dashboard/config/linux/upstream-arm64-mte.config FWIW, I keep my fuzzing config fragment in my fuzzing/* branches on git.kernel.org, and for comparison my fragment for v5.12-rc1 is: https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/commit/?h=fuzzing/5.12-rc1&id=6d9f7f8a2514fe882823fadbe7478228f71d7ab1 ... I'm not sure whether there's anything in that which is novel to you. > The instances have KCOV disabled because it slows down execution too > much (KASAN in qemu emulation is already extremely slow), so no > coverage guidance and coverage reports for now :( > > The instances found few arm64-specific issues that we have not > observed on other instances: > https://syzkaller.appspot.com/bug?id=1d22a2cc3521d5cf6b41bd6b825793c2015f861f > https://syzkaller.appspot.com/bug?id=bb2c16b0e13b4de4bbf22cf6a4b9b16fb0c20eea > https://syzkaller.appspot.com/bug?id=b75386f45318ec181b7f49260d619fac9877d456 > https://syzkaller.appspot.com/bug?id=5a1bc29bca656159f95c7c8bb30e3776ca860332 > but mostly re-discovering known bugs we already found on x86. Likewise, my general experience these days (fuzzing under KVM on a ThunderX2 host) is that we mostly hit issues in core code or drivers rather than anything strictly specific to arm64. As my host is ARMv8.1 that might just be by virtue of not exercising many of the new architectural features. > The instances use qemu emulation and lots of debug configs, so they > are quite slow and it makes sense to target them at arm64-specific > parts of the kernel as much as possible (rather > than stress generic subsystems that are already stressed on x86). > So the question is: what arm64-specific parts are there that we can reach > in qemu? > Can you think of any qemu flags (cpu features, device emulation, etc)? Generally, `-cpu max` will expose the more interesting CPU features, and you already seem to have that, so I think you're mostly there on that front. Devices vary a lot between SoCs (and most aren't even emulated), so unless you have particular platforms in mind I'd suggest it might be better to just use PV devices and try to focus fuzzing on arch code and common code like mm rather than drivers. > Any kernel subsystems with heavy arm-specific parts that we may be missing? It looks like your configs already have BPF, which is probably one of the more interesting subsystems with architecture-specific bits, so I don't have further suggestions on that front. > Testing some of the arm64 drivers that qemu can emulate may be the > most profitable thing. > Currently the instances use the following flags: > -machine virt,virtualization=on,graphics=on,usb=on -cpu cortex-a57 > -machine virt,virtualization=on,mte=on,graphics=on,usb=on -cpu max With `-cpu max`, QEMU will use a relatively expensive SW implementation of pointer authentication (which I found significantly magnified the cost of implementation like kcov), so depending on your priorities you might want to disable that or (assuming you have a recent enough build of QEMU) you might wantto force the use of a cheaper algorithm by passing `-cpu max,pauth-impef`. The relevant QEMU commit is: eb94284d0812b4e7 ("arget/arm: Add cpu properties to control pauth") ... but it looks like that might not yet be in a tagged release yet. Thanks, Mark. > mte=on + virtualization=on is broken in the kernel on in the qemu: > https://lore.kernel.org/lkml/CAAeHK+wDz8aSLyjq1b=q3+HG9aJXxwYR6+gN_fTttMN5osM5gg@mail.gmail.com/ > > -- > You received this message because you are subscribed to the Google Groups "syzkaller" group. > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/CACT4Y%2BbeyZ7rjmy7im0KdSU-Pcqd4Rud3xsxonBbYVk0wU-B9g%40mail.gmail.com. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel