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=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 C68FBC433DF for ; Sun, 24 May 2020 13:41:29 +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 8996320878 for ; Sun, 24 May 2020 13:41:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="TWQvaisv" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8996320878 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:60492 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcqsa-0001Z6-QA for qemu-devel@archiver.kernel.org; Sun, 24 May 2020 09:41:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40542) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jcqs2-0000yk-Qg for qemu-devel@nongnu.org; Sun, 24 May 2020 09:40:54 -0400 Received: from mail-ot1-x336.google.com ([2607:f8b0:4864:20::336]:39418) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jcqs1-00080N-Tr for qemu-devel@nongnu.org; Sun, 24 May 2020 09:40:54 -0400 Received: by mail-ot1-x336.google.com with SMTP id d7so11977244ote.6 for ; Sun, 24 May 2020 06:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=kiPK2qmDv3F+OA9Mn5nH21zVPtkpK5TkFrKWMdMlwr8=; b=TWQvaisvFK1NTxyt8lqXjhQJYUWnwBwucRdhsVOZVS0ttUjGE1hN8AkdKY/yuHXoev woqoRQGScwTUELIkjJheKcVTaSAHtViquvmIgtMXMrxB2L+CzTkQAWfSqInhk/5in4Cy Fik90djhQhldoaYVQb2UXiKCjH/zBHKT78r5umPGIbEi1iDOTHrg6+0Q5/8Kkg3ppDli rZahfJB5RuSZwL69qeT4mnc3Vzdigs+H1qqOLhdo+MuPsgz4Ea7txrG+h2mtkRMNK9Pq rwis0hQsjIh7/xK5eX5p9aWpVbEXMK8JaodL6oiv5oLCo7GFPkiV2TI0J4GXygMSgrNZ daqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=kiPK2qmDv3F+OA9Mn5nH21zVPtkpK5TkFrKWMdMlwr8=; b=WiQuhCjxkqKFx2rkXqbzCB/PNAS9xzTMM4zwUVXpjJhC31OSZozUHDAT1NgmRHYJ7Y KZrC0eVlIGZCMJaYYCeRSG40KGXb2aO5aYTGNHvqKxRI8w/4WjbnEQa9/nFfGco2ergL wJ7EHq/5o2ubo9C3r+HbOJJqe1iI8VWoLiFyek0dOobqREx7exkymDpKEWDwuAKHZXNm S/o3VKp1t9ItO2NNzWTl5kBbh4P7HQXsFAUIWLK14C8w1iRI3DnoPCbBi25a2vbgQL62 6rKFoOfSpJgV1EGtyzQEzU+MTzTqC4os1YDtVm0CdMR+aYegLYP8kEyiHucsMLz66icR KJGA== X-Gm-Message-State: AOAM530zmZsZtIp/RCwUwjW2s1sj84KM9P7SbFB5dfLlMS9FhuOTzcGF 8naRAGnwpGDMLKReRhWbTTCz8YF4DvCGF6AIqwWCAQ== X-Google-Smtp-Source: ABdhPJzlUIz/vqoZnQqDSM8+JLJ4vRVPXDsZ9M7Oejbm5MFRmbM56cE8/LSrUfGWcny4M+eARcfdGSOWnISlQxECA3M= X-Received: by 2002:a9d:3623:: with SMTP id w32mr17520707otb.91.1590327652737; Sun, 24 May 2020 06:40:52 -0700 (PDT) MIME-Version: 1.0 References: <159029353528.907.11982786579949073896.malonedeb@chaenomeles.canonical.com> In-Reply-To: From: Peter Maydell Date: Sun, 24 May 2020 14:40:41 +0100 Message-ID: Subject: Re: [Bug 1880355] [NEW] Length restrictions for fw_cfg_dma_transfer? To: =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::336; envelope-from=peter.maydell@linaro.org; helo=mail-ot1-x336.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Michael S. Tsirkin" , Mark Cave-Ayland , QEMU Developers , Bug 1880355 <1880355@bugs.launchpad.net>, Gerd Hoffmann , Paolo Bonzini , Laszlo Ersek Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Sun, 24 May 2020 at 11:30, Philippe Mathieu-Daud=C3=A9 wrote: > It looks to me a normal behavior for a DMA device. DMA devices have a > different address space view than the CPUs. > Also note the fw_cfg is a generic device, not restricted to the x86 arch. In an ideal world all our DMA devices would use some kind of common framework or design pattern so they didn't hog all the CPU and/or spend minutes with the BQL held if the guest requests an enormous-sized DMA. In practice many of them just have a simple "loop until the DMA transfer is complete" implementation... thanks -- PMM 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=-0.8 required=3.0 tests=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 AA61CC433E0 for ; Sun, 24 May 2020 13:51:15 +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 7973020776 for ; Sun, 24 May 2020 13:51:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7973020776 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]:43394 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcr22-0006qG-KN for qemu-devel@archiver.kernel.org; Sun, 24 May 2020 09:51:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41144) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jcr1S-0006I4-Eq for qemu-devel@nongnu.org; Sun, 24 May 2020 09:50:38 -0400 Received: from indium.canonical.com ([91.189.90.7]:42754) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jcr1R-0000eh-84 for qemu-devel@nongnu.org; Sun, 24 May 2020 09:50:38 -0400 Received: from loganberry.canonical.com ([91.189.90.37]) by indium.canonical.com with esmtp (Exim 4.86_2 #2 (Debian)) id 1jcr1P-0006p9-2C for ; Sun, 24 May 2020 13:50:35 +0000 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id 0CB142E8029 for ; Sun, 24 May 2020 13:50:35 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 May 2020 13:40:41 -0000 From: Peter Maydell <1880355@bugs.launchpad.net> To: qemu-devel@nongnu.org X-Launchpad-Notification-Type: bug X-Launchpad-Bug: product=qemu; status=New; importance=Undecided; assignee=None; X-Launchpad-Bug-Information-Type: Public X-Launchpad-Bug-Private: no X-Launchpad-Bug-Security-Vulnerability: no X-Launchpad-Bug-Commenters: a1xndr philmd pmaydell X-Launchpad-Bug-Reporter: Alexander Bulekov (a1xndr) X-Launchpad-Bug-Modifier: Peter Maydell (pmaydell) References: <159029353528.907.11982786579949073896.malonedeb@chaenomeles.canonical.com> Message-ID: Subject: Re: [Bug 1880355] [NEW] Length restrictions for fw_cfg_dma_transfer? 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="1f7bc749b40714a4cc10f5e4d787118a78037035"; Instance="production-secrets-lazr.conf" X-Launchpad-Hash: 9c5c524f4a7f3644b9930c7748ec93d068f788b5 Received-SPF: none client-ip=91.189.90.7; envelope-from=bounces@canonical.com; helo=indium.canonical.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/24 09:50:35 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] 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.249, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN 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 1880355 <1880355@bugs.launchpad.net> Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Message-ID: <20200524134041.tI5QT94m3zkxYQuM-67Y8mKPhlcomWmPI6Mj9OctEf0@z> On Sun, 24 May 2020 at 11:30, Philippe Mathieu-Daud=C3=A9 wrote: > It looks to me a normal behavior for a DMA device. DMA devices have a > different address space view than the CPUs. > Also note the fw_cfg is a generic device, not restricted to the x86 arch. In an ideal world all our DMA devices would use some kind of common framework or design pattern so they didn't hog all the CPU and/or spend minutes with the BQL held if the guest requests an enormous-sized DMA. In practice many of them just have a simple "loop until the DMA transfer is complete" implementation... thanks -- PMM -- = You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1880355 Title: Length restrictions for fw_cfg_dma_transfer? Status in QEMU: New Bug description: For me, this takes close to 3 minutes at 100% CPU: echo "outl 0x518 0x9596ffff" | ./i386-softmmu/qemu-system-i386 -M q35 -m = 32 -nographic -accel qtest -monitor none -serial none -qtest stdio #0 phys_page_find (d=3D0x606000035d80, addr=3D136728041144404) at /exec.= c:338 #1 address_space_lookup_region (d=3D0x606000035d80, addr=3D1367280411444= 04, resolve_subpage=3Dtrue) at /exec.c:363 #2 address_space_translate_internal (d=3D0x606000035d80, addr=3D13672804= 1144404, xlat=3D0x7fff1fc0d070, plen=3D0x7fff1fc0d090, resolve_subpage=3Dtr= ue) at /exec.c:382 #3 flatview_do_translate (fv=3D0x606000035d20, addr=3D136728041144404, x= lat=3D0x7fff1fc0d070, plen_out=3D0x7fff1fc0d090, page_mask_out=3D0x0, is_wr= ite=3Dtrue, is_mmio=3Dtrue, target_as=3D0x7fff1fc0ce10, attrs=3D...) pment/qemu/exec.c:520 #4 flatview_translate (fv=3D0x606000035d20, addr=3D136728041144404, xlat= =3D0x7fff1fc0d070, plen=3D0x7fff1fc0d090, is_write=3Dtrue, attrs=3D...) at = /exec.c:586 #5 flatview_write_continue (fv=3D0x606000035d20, addr=3D136728041144404,= attrs=3D..., ptr=3D0x7fff1fc0d660, len=3D172, addr1=3D136728041144400, l= =3D172, mr=3D0x557fd54e77e0 ) pment/qemu/exec.c:3160 #6 flatview_write (fv=3D0x606000035d20, addr=3D136728041144064, attrs=3D= ..., buf=3D0x7fff1fc0d660, len=3D512) at /exec.c:3177 #7 address_space_write (as=3D0x557fd54e7a00 , addr= =3D136728041144064, attrs=3D..., buf=3D0x7fff1fc0d660, len=3D512) at /exec.= c:3271 #8 dma_memory_set (as=3D0x557fd54e7a00 , addr=3D13= 6728041144064, c=3D0 '\000', len=3D1378422272) at /dma-helpers.c:31 #9 fw_cfg_dma_transfer (s=3D0x61a000001e80) at /hw/nvram/fw_cfg.c:400 #10 fw_cfg_dma_mem_write (opaque=3D0x61a000001e80, addr=3D4, value=3D4294= 940309, size=3D4) at /hw/nvram/fw_cfg.c:467 #11 memory_region_write_accessor (mr=3D0x61a000002200, addr=3D4, value=3D= 0x7fff1fc0e3d0, size=3D4, shift=3D0, mask=3D4294967295, attrs=3D...) at /me= mory.c:483 #12 access_with_adjusted_size (addr=3D4, value=3D0x7fff1fc0e3d0, size=3D4= , access_size_min=3D1, access_size_max=3D8, access_fn=3D0x557fd2288c80 , mr=3D0x61a000002200, attrs=3D...) pment/qemu/memory.c:539 #13 memory_region_dispatch_write (mr=3D0x61a000002200, addr=3D4, data=3D4= 294940309, op=3DMO_32, attrs=3D...) at /memory.c:1476 #14 flatview_write_continue (fv=3D0x606000035f00, addr=3D1304, attrs=3D..= ., ptr=3D0x7fff1fc0ec40, len=3D4, addr1=3D4, l=3D4, mr=3D0x61a000002200) at= /exec.c:3137 #15 flatview_write (fv=3D0x606000035f00, addr=3D1304, attrs=3D..., buf=3D= 0x7fff1fc0ec40, len=3D4) at /exec.c:3177 #16 address_space_write (as=3D0x557fd54e7bc0 , addr=3D1= 304, attrs=3D..., buf=3D0x7fff1fc0ec40, len=3D4) at /exec.c:3271 = It looks like fw_cfg_dma_transfer gets the address(136728041144064) and l= ength(1378422272) for the read from the value provided as input 4294940309 = (0xFFFF9695) which lands in pcbios. Should there be any limits on the lengt= h of guest-memory that fw_cfg should populate? Found by libfuzzer To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1880355/+subscriptions