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.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 3DAC7C2B9F2 for ; Sat, 22 May 2021 05:26:54 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (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 325C5611F0 for ; Sat, 22 May 2021 05:26:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 325C5611F0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bugs.launchpad.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:54020 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lkKA0-0005Be-4q for qemu-devel@archiver.kernel.org; Sat, 22 May 2021 01:26:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41518) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lkK8u-0003sd-6B for qemu-devel@nongnu.org; Sat, 22 May 2021 01:25:44 -0400 Received: from indium.canonical.com ([91.189.90.7]:34590) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lkK8r-0002IL-Ug for qemu-devel@nongnu.org; Sat, 22 May 2021 01:25:43 -0400 Received: from loganberry.canonical.com ([91.189.90.37]) by indium.canonical.com with esmtp (Exim 4.93 #5 (Debian)) id 1lkK8n-00045U-Np for ; Sat, 22 May 2021 05:25:37 +0000 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id 8E6ED2E8188 for ; Sat, 22 May 2021 05:25:37 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Sat, 22 May 2021 05:12:48 -0000 From: Peter Collingbourne <1921948@bugs.launchpad.net> To: qemu-devel@nongnu.org X-Launchpad-Notification-Type: bug X-Launchpad-Bug: product=qemu; status=Confirmed; importance=Undecided; assignee=rth@twiddle.net; X-Launchpad-Bug-Information-Type: Public X-Launchpad-Bug-Private: no X-Launchpad-Bug-Security-Vulnerability: no X-Launchpad-Bug-Commenters: ajbennee pcc-goog pmaydell rth xairy X-Launchpad-Bug-Reporter: Andrey Konovalov (xairy) X-Launchpad-Bug-Modifier: Peter Collingbourne (pcc-goog) References: <161713286145.25906.15042270704525675392.malonedeb@wampee.canonical.com> Message-Id: <162166036904.31210.7979340331875916775.malone@gac.canonical.com> Subject: [Bug 1921948] Re: MTE tags not checked properly for unaligned accesses at EL1 X-Launchpad-Message-Rationale: Subscriber (QEMU) @qemu-devel-ml X-Launchpad-Message-For: qemu-devel-ml Precedence: bulk X-Generated-By: Launchpad (canonical.com); Revision="ba75dbf44f1013379e594c259682f14c0528180a"; Instance="production" X-Launchpad-Hash: da9827eecc7c56d4596fd56ed6cfd736f9f8b4d7 Received-SPF: none client-ip=91.189.90.7; envelope-from=bounces@canonical.com; helo=indium.canonical.com X-Spam_score_int: -65 X-Spam_score: -6.6 X-Spam_bar: ------ X-Spam_report: (-6.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Bug 1921948 <1921948@bugs.launchpad.net> Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" It looks like there's still a bug here: I'm seeing false positive MTE faults for unaligned accesses that touch multiple pages. This userspace assembly program demonstrates the problem, but for some reason it only reproduces some of the time for me: .arch_extension memtag .globl _start _start: mov x0, #0x37 // PR_SET_TAGGED_ADDR_CTRL mov x1, #0x3 // PR_TAGGED_ADDR_ENABLE | PR_MTE_TCF_ASYNC mov x2, #0 mov x3, #0 mov x4, #0 mov x8, #0xa7 // prctl svc #0 mov x0, xzr mov w1, #0x2000 mov w2, #0x23 // PROT_READ|PROT_WRITE|PROT_MTE mov w3, #0x22 // MAP_PRIVATE|MAP_ANONYMOUS mov w4, #0xffffffff mov x5, xzr mov x8, #0xde // mmap svc #0 mov x1, #(1 << 56) add x0, x0, x1 add x0, x0, #0xff0 stg x0, [x0] stg x0, [x0, #16] str x1, [x0, #12] mov x0, #0 mov x8, #0x5d // exit svc #0 ** Changed in: qemu Status: Fix Committed =3D> Confirmed -- = You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1921948 Title: MTE tags not checked properly for unaligned accesses at EL1 Status in QEMU: Confirmed Bug description: For kernel memory accesses that span across two memory granules, QEMU's MTE implementation only checks the tag of the first granule but not of the second one. To reproduce this, build the Linux kernel with CONFIG_KASAN_HW_TAGS enabled, apply the patch below, and boot the kernel: diff --git a/sound/last.c b/sound/last.c index f0bb98780e70..04745cb30b74 100644 --- a/sound/last.c +++ b/sound/last.c @@ -5,12 +5,18 @@ */ = #include +#include #include = static int __init alsa_sound_last_init(void) { struct snd_card *card; int idx, ok =3D 0; + + char *ptr =3D kmalloc(128, GFP_KERNEL); + pr_err("KASAN report should follow:\n"); + *(volatile unsigned long *)(ptr + 124); + kfree(ptr); = printk(KERN_INFO "ALSA device list:\n"); for (idx =3D 0; idx < SNDRV_CARDS; idx++) { KASAN tags the 128 allocated bytes with the same tag as the returned pointer. The memory granule that follows the 128 allocated bytes has a different tag (with 1/15 probability). Expected result: a tag fault is detected and a KASAN report is printed wh= en accessing bytes [124, 130). Observed result: no tag fault is detected and no KASAN report is printed. Here are the flags that I use to run QEMU if they matter: qemu-system-aarch64 -s -machine virt,mte=3Don -cpu max -m 2G -smp 2 -net user,host=3D10.0.2.10,hostfwd=3Dtcp:127.0.0.1:10021-:22 -net nic -nographic -kernel ./Image -append "console=3DttyAMA0 root=3D/dev/vda earlyprintk=3Dserial" -drive file=3D./fs.img,format=3Draw,if=3Dvirtio -no- shutdown -no-reboot To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1921948/+subscriptions