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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B15E3C433FE for ; Mon, 14 Feb 2022 17:14:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1356963AbiBNROl (ORCPT ); Mon, 14 Feb 2022 12:14:41 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:46044 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356955AbiBNROj (ORCPT ); Mon, 14 Feb 2022 12:14:39 -0500 Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E3ABC65173 for ; Mon, 14 Feb 2022 09:14:31 -0800 (PST) Received: by mail-pj1-x1036.google.com with SMTP id b8so3293447pjb.4 for ; Mon, 14 Feb 2022 09:14:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=auHdDKcE/HC+BDwZpCPvw9X/g5EzgIbYvOhoHY8/cJY=; b=JbvD4yatDBiI12WQDdeOK5f0z8ngSNl6pVxPJJnhEgNasmDkLcTlLZcpmzyfzAlJFa MetFFN9apMVPRUdfITZo7Euk4O4YzfwoPU+M2d0VQhg/3e+RF4PfjKj8SBcERdDVFUxo kYTP8O8GVkrjlu0Z2kYe6W1ZkVCOLGGcBuJ8WU/8CiCXyFP+pGT3zZXNmQlTEp2+9LNc uCtfng0MRDpXhl7s8DCo4+MPagjhhfH0v4HLXgkx/9LBDqXT6P7PuRTUGtd9usCULgyk ILDKui5NWOzFiO8twcW5SPuMKuaoDwaunCs6x6QkEh4np2NzN7uwC1YUcjtDfeplP+ej DByg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=auHdDKcE/HC+BDwZpCPvw9X/g5EzgIbYvOhoHY8/cJY=; b=wO9saaORDdpjpw/HHpvl4zomojiU9SEZMd/q0LxpOL6tKfHCzeYWZRWn5J2n7TiVXo 1bn8bqfugeFtwUIfXq+CfTTQoPPVnDgitqxpUMRJO6b/ghsGXicehlOCU8ISwkBl4JJn 7u/R0ECCZA9EzlDC7l0AFyuX8YN0yIDWARG3mYhLRXzslpeAEIHidv3XoeP0ERAouXrC w696e0dSG1MqpqPHxODpYq/ZSoSPlrB9D1EfUgg8F3govMjcCseE05TvuEA83bcSlSs6 YsQChrwlXbbLMcqQk5AJiN1hW/8rbR3GRbKFNrMutEZNRPkGJ6pQkdxW7jXDiSCWTr4r mpKg== X-Gm-Message-State: AOAM532HjGoyhyW4VpQZpCefxvKrQGdUcv36jbeFmFaW2u3uFVHb1Ypa iLI6fd74/iIHyXC6JoIQVZc7zw== X-Google-Smtp-Source: ABdhPJzdzHWiOyC2Kri7/kYcALouqtq1nTXz3EXMpUbYNwNQVqhhju24GuUtyviHjqlDyupx7DWUlA== X-Received: by 2002:a17:90b:1d84:: with SMTP id pf4mr6833277pjb.124.1644858871225; Mon, 14 Feb 2022 09:14:31 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id k9sm34903413pfi.134.2022.02.14.09.14.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Feb 2022 09:14:30 -0800 (PST) Date: Mon, 14 Feb 2022 17:14:27 +0000 From: Sean Christopherson To: "Woodhouse, David" Cc: Paolo Bonzini , Christian Borntraeger , Janosch Frank , David Hildenbrand , Claudio Imbrenda , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] KVM: Don't actually set a request when evicting vCPUs for GFN cache invd Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Feb 12, 2022, Woodhouse, David wrote: > > (Apologies if this is HTML but I'm half-way to Austria and the laptop is > buried somewhere in the car, and access to work email with sane email apps is > difficult.) > > On 12 Feb 2022 03:05, Sean Christopherson wrote: > > Don't actually set a request bit in vcpu->requests when making a request > purely to force a vCPU to exit the guest. Logging the request but not > actually consuming it causes the vCPU to get stuck in an infinite loop > during KVM_RUN because KVM sees a pending request and bails from VM-Enter > to service the request. > > > Right, but there is no extant code which does this. The guest_uses_pa flag is > unused. Grr. A WARN or something would have been nice to have. Oh well. > The series came with a proof-of-concept that attempted using it for > fixing nesting UAFs but it was just that — a proof of concept to demonstrate > that the new design of GPC was sufficient to address that problem. > > IIRC, said proof of concept did also actually consume the req in question, It did. I saw that, but obviously didn't connect the dots to guest_uses_pa. --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -9826,6 +9826,8 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) if (kvm_check_request(KVM_REQ_UPDATE_CPU_DIRTY_LOGGING, vcpu)) static_call(kvm_x86_update_cpu_dirty_logging)(vcpu); + if (kvm_check_request(KVM_REQ_GPC_INVALIDATE, vcpu)) + ; /* Nothing to do. It just wanted to wake us */ > and one of the existing test cases did exercise it with an additional mmap > torture added? Of course until we have kernel code that *does* this, it's > hard to exercise it from userspace :) Indeed. I'll send a new version with a different changelog, that way we're not leaving a trap for developers and each architecture doesn't need to manually handle the request. Thanks!