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=-10.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 8677EC433DB for ; Tue, 2 Feb 2021 09:53:24 +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 98D9864F54 for ; Tue, 2 Feb 2021 09:53:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 98D9864F54 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]:46902 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l6sN8-0007rk-H7 for qemu-devel@archiver.kernel.org; Tue, 02 Feb 2021 04:53:22 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43138) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l6sM5-0007Pf-6P for qemu-devel@nongnu.org; Tue, 02 Feb 2021 04:52:17 -0500 Received: from mail-ej1-x630.google.com ([2a00:1450:4864:20::630]:40403) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l6sM3-0003TH-H5 for qemu-devel@nongnu.org; Tue, 02 Feb 2021 04:52:16 -0500 Received: by mail-ej1-x630.google.com with SMTP id i8so12488534ejc.7 for ; Tue, 02 Feb 2021 01:52:15 -0800 (PST) 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; bh=3UApUxOaJP+t6fV9jHDHIoe/lBEmmZCaRZndQmeCaNQ=; b=fxTPgBk5PV6ClcV9p4GVeakuzhJl9BeOC73OlaIpZBqkg7mYCmsQrqwG64kv/Qu7qB jQDi0TPoU85Jtat3wx4LKe5f7h9RTKrnzbNe+dC4581hGqkmAyGtrHl7QHD9b4kUbZ5o C+uIbv7GQoMe2jFlv7zduqSxPXkCaVM97KYQQBrGwyDpLs9XzzDfXcWstXS22gZfRpgz kDYnq/xQGiMqbluUXVIZ/GyOKpWFLxfTPrPfA3KJr2Uv4PTSoh4eQgHNYXPsrAU5EEH/ 5M6U94HutNPDX8hSbCcB/kJ/hT7pDpTv8yw9qQWekEL+uAaYh0242fjy6cLKuG00smeM Js8Q== 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; bh=3UApUxOaJP+t6fV9jHDHIoe/lBEmmZCaRZndQmeCaNQ=; b=c5PrmDx1QAi6a1+r9sOYn+Bv4TiwYKIYJo+a9H0tjbBWZq/b3NfxV1nAghlpazJCsg Z8ShFUTuw+mMQUzB18VkMIK89Fma7CycU1cuXUbSqnek+da1CdXJNRE6S+dOFHSZWYKT lg3ARbrixj2k6m0lJDP85HNXfJVTmVQPdWdT/DLgc8IdiXfhw/HIq9vI2g8KWO+2BBNm PzL/uLKrIj7sJ2rHRajIn//LjJ6X2d2r7ki4gXm8qJiszkA/be0Lxl6aqADwIIfMeRjT kAPhexytjFhzLid2zRn0U0lcQrpQ7ljly/l09v7kCpT3XdAIMqC7OXQbpzGKfmVARVQJ zECw== X-Gm-Message-State: AOAM533LhfuLmyVR9plxUXzZ3OX72tjS+aBkGFnq30ZcCcMJrxXFBNJJ 0in5xmb6l4XVfNMMM5bTjf2KS08aaI58IjkE85q2tQ== X-Google-Smtp-Source: ABdhPJza2bFH/YqXQbrpk0ThFHUodhuy3ihqdc49nWfq097v1u8WQCCYlpnlPlG0IbClC+qOJpCtWsuYfKQ1x9fP4Hg= X-Received: by 2002:a17:906:2747:: with SMTP id a7mr22441433ejd.250.1612259533861; Tue, 02 Feb 2021 01:52:13 -0800 (PST) MIME-Version: 1.0 References: <161049230444.13717.10732991676985431455.malonedeb@gac.canonical.com> <161224193914.13121.15293709183751600564.malone@soybean.canonical.com> In-Reply-To: <161224193914.13121.15293709183751600564.malone@soybean.canonical.com> From: Peter Maydell Date: Tue, 2 Feb 2021 09:52:02 +0000 Message-ID: Subject: Re: [Bug 1911351] Re: x86-64 MTTCG Does not update page table entries atomically To: Bug 1911351 <1911351@bugs.launchpad.net> Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::630; envelope-from=peter.maydell@linaro.org; helo=mail-ej1-x630.google.com 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_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no 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: QEMU Developers Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Tue, 2 Feb 2021 at 05:07, Venkatesh Srinivas <1911351@bugs.launchpad.net> wrote: > BTW, the RISC-V MMU code _does_ get this right and the model could be > followed by the x86 version - - something like > https://github.com/vsrinivas/qemu/commit/1efa7dc689c4572d8fe0880ddbe44ec22f8f4348, > (but with more compiling + working) might solve this problem and more > closely model h/w target/i386 is the wrong place to put the fix, though: the abstraction layers for working with AddressSpaces need to provide atomic operations and then under the hood do the right thing to implement them. target-specific code shouldn't need to manually do the translation, fish out a MemoryRegion, check whether it's really host RAM, and so on. 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=-8.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 59181C433E0 for ; Tue, 2 Feb 2021 10:02:55 +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 563C564E30 for ; Tue, 2 Feb 2021 10:02:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 563C564E30 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]:52786 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l6sWL-0002l9-6w for qemu-devel@archiver.kernel.org; Tue, 02 Feb 2021 05:02:53 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45078) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l6sV4-0001uD-Sj for qemu-devel@nongnu.org; Tue, 02 Feb 2021 05:01:34 -0500 Received: from indium.canonical.com ([91.189.90.7]:52084) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l6sUz-0007kY-9A for qemu-devel@nongnu.org; Tue, 02 Feb 2021 05:01:34 -0500 Received: from loganberry.canonical.com ([91.189.90.37]) by indium.canonical.com with esmtp (Exim 4.86_2 #2 (Debian)) id 1l6sUx-0005JM-6l for ; Tue, 02 Feb 2021 10:01:27 +0000 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id 293DE2E813B for ; Tue, 2 Feb 2021 10:01:27 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Tue, 02 Feb 2021 09:52:02 -0000 From: Peter Maydell <1911351@bugs.launchpad.net> To: qemu-devel@nongnu.org X-Launchpad-Notification-Type: bug X-Launchpad-Bug: product=qemu; status=Confirmed; importance=Undecided; assignee=None; X-Launchpad-Bug-Tags: i386 tcg X-Launchpad-Bug-Information-Type: Public X-Launchpad-Bug-Private: no X-Launchpad-Bug-Security-Vulnerability: no X-Launchpad-Bug-Commenters: charco pmaydell venkatesh-srinivas X-Launchpad-Bug-Reporter: Marco (charco) X-Launchpad-Bug-Modifier: Peter Maydell (pmaydell) References: <161049230444.13717.10732991676985431455.malonedeb@gac.canonical.com> <161224193914.13121.15293709183751600564.malone@soybean.canonical.com> Message-ID: Subject: Re: [Bug 1911351] Re: x86-64 MTTCG Does not update page table entries atomically 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="3d7abcb776ec05aa0a89112accc21bf8b41dfc24"; Instance="production" X-Launchpad-Hash: 6194ac8ecebe56701e8b142b535d16a822e1a0f8 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 1911351 <1911351@bugs.launchpad.net> Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Message-ID: <20210202095202.hlJ7WSm-mRcUMO4aCENOA3fRNhKU-ktOHk3Iilqy_Ws@z> On Tue, 2 Feb 2021 at 05:07, Venkatesh Srinivas <1911351@bugs.launchpad.net> wrote: > BTW, the RISC-V MMU code _does_ get this right and the model could be > followed by the x86 version - - something like > https://github.com/vsrinivas/qemu/commit/1efa7dc689c4572d8fe0880ddbe44ec2= 2f8f4348, > (but with more compiling + working) might solve this problem and more > closely model h/w target/i386 is the wrong place to put the fix, though: the abstraction layers for working with AddressSpaces need to provide atomic operations and then under the hood do the right thing to implement them. target-specific code shouldn't need to manually do the translation, fish out a MemoryRegion, check whether it's really host RAM, and so on. 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/1911351 Title: x86-64 MTTCG Does not update page table entries atomically Status in QEMU: Confirmed Bug description: It seems like the qemu tcg code for x86-64 doesn't write the access and dirty bits of the page table entries atomically. Instead, they first read the entry, see if they need to set the page table entry, and then write back the updated page table entry. So if you have two threads running at the same time, one accessing the virtual address over and over again, and the other modifying the page table entry, it is possible that after the second thread modifies the page table entry, qemu overwrites the value with the old page table entry value, with the access/dirty flags set. Here's a unit test that reproduces this behavior: https://github.com/mvanotti/kvm-unit- tests/commit/09f9722807271226a714b04f25174776454b19cd You can run it with: ``` /usr/bin/qemu-system-x86_64 --no-reboot -nodefaults \ -device pc-testdev -device isa-debug-exit,iobase=3D0xf4,iosize=3D0x4 \ -vnc none -serial stdio -device pci-testdev \ -smp 4 -machine q35 --accel tcg,thread=3Dmulti \ -kernel x86/mmu-race.flat # -initrd /tmp/tmp.avvPpezMFf ``` Expected output (failure): ``` kvm-unit-tests$ make && /usr/bin/qemu-system-x86_64 --no-reboot -nodefaul= ts -device pc-testdev -device isa-debug-exit,iobase=3D0xf4,iosize=3D0x4 -vn= c none -serial stdio -device pci-testdev -smp 4 -machine q35 --accel tcg,th= read=3Dmulti -kernel x86/mmu-race.flat # -initrd /tmp/tmp.avvPpezMFf enabling apic enabling apic enabling apic enabling apic paging enabled cr0 =3D 80010011 cr3 =3D 627000 cr4 =3D 20 found 4 cpus PASS: Need more than 1 CPU Detected overwritten PTE: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0want: 0x000000000062e007 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0got: 0x000000000062d027 FAIL: PTE not overwritten PASS: All Reads were zero SUMMARY: 3 tests, 1 unexpected failures ``` This bug allows user-to-root privilege escalation inside the guest VM: if the user is able overwrite an entry that belongs to a second-to- last level page table, and is able to allocate the referenced page, then the user would be in control of a last-level page table, being able to map any memory they want. This is not uncommon in situations where memory is being decomitted. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1911351/+subscriptions