From patchwork Wed Mar 22 14:12:20 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Christopherson X-Patchwork-Id: 73453 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:604a:0:0:0:0:0 with SMTP id j10csp2368244wrt; Wed, 22 Mar 2023 07:21:06 -0700 (PDT) X-Google-Smtp-Source: AK7set8pw9mZSxuVwynzsBKwtpO7itEDLst4peTnZs4tAPBtsNpcvY56x95pPtzsl/wJMXd3hkPW X-Received: by 2002:a17:903:808:b0:199:10d2:b9da with SMTP id kr8-20020a170903080800b0019910d2b9damr2602089plb.58.1679494866341; Wed, 22 Mar 2023 07:21:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679494866; cv=none; d=google.com; s=arc-20160816; b=MFi/4byqM1MgUJxkgiRNoPVOH/z00798gZjo/OV8p/SwO8QK59W54ENoSn+vKbdZZA wVSZ9cbOOczTnQ3tsotw6wcYcMUPy3DlsIR8Hi9zVECFWc5Rx30jUd1VlqkcO/jaROiK ac6xGBmODGANPs3jhgQsXn+JuCbY0AcvaL6ZbYm26t/TiVe+ddifd7RE3PLwLiiEQkpe Ejt+S2WDO0RMzGOPTReYbIwYf5TklCys5A34Gpy8UK+/oF1GWYglXMWZvxzCYnfK5aDB bB/7onlDCMCsbFZUv31Di8nuwJGB4FGtr2fP6t2G2Z1sXOBL7EC0vcEvS/aH7Bm5e9yW Th1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :reply-to:dkim-signature; bh=h3g8Rn77aV2QcyJGm9ePKuJvFxr4MQGLJYaNKJMKDWU=; b=jiqQOPRrOtLs+dR9HmYNsrTbRf+9LlGI3+GmS63llKGydRTPZjxqnYM/rrPi12dMEj GdxPFFoSQNz/yhB1DxNXr48802wgYwAJjm7TS2WqSKtqLCMzbmX8KTqS6tpDJ3Y6Z67i HH11yKYC6+7PrFlZeLfOZHwtCjphLpWYRN1P7X27zGqWY5n7h2Pu/rwCl//ZV77LA1QC uPVfbJ+pKOYVSQg9IRTiVHWRULkn6DbtH/cD/r/nBE4aC7E9amfnUdY+WPs3gbKvpACD buBdN+yxJTZ/Fl8HoqFdezwaCZ6SXYMlPuWkFXHKi40jnQWnlwP99uXfsMWWByBM+18m j0CA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=r3mX0acH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q5-20020a17090311c500b0019f34a15738si16942410plh.139.2023.03.22.07.20.54; Wed, 22 Mar 2023 07:21:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=r3mX0acH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229541AbjCVOMi (ORCPT + 99 others); Wed, 22 Mar 2023 10:12:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37272 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229794AbjCVOMe (ORCPT ); Wed, 22 Mar 2023 10:12:34 -0400 Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 211CD6486F for ; Wed, 22 Mar 2023 07:12:24 -0700 (PDT) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-54476ef9caeso188065817b3.6 for ; Wed, 22 Mar 2023 07:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1679494343; h=cc:to:from:subject:message-id:mime-version:date:reply-to:from:to:cc :subject:date:message-id:reply-to; bh=h3g8Rn77aV2QcyJGm9ePKuJvFxr4MQGLJYaNKJMKDWU=; b=r3mX0acHgQFJ/12GN3ObmLvXudUkJrxw9cCmhw7vFuhOdavMwvBHJvlPQzoM9ZnLwg MvwtnJVXs2hfUcZXcO4ksYztfpbTOdQtPxGfDGOu7ZKeA3KBKO5HgxS5D+oIvjUJZut5 YdZe0Fkq8vI1FqZp//uQpLX/+hvNC9g8yAp8rYj6poswJxK9Qe7fIYyAmWN/Ts7SCtrW l/9hx6gJ+y3K29/RprDY2OpfnUqLLdinU1/+HANADLUpUJRRcMHNhrEoUT3E9DPucq4x OZgeodp/IwCYc6WqkL4h46eiziMvO7xKLFNh2Ruh4CQiLEIeue98vW88tqjs4djKGlhQ f3VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679494343; h=cc:to:from:subject:message-id:mime-version:date:reply-to :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=h3g8Rn77aV2QcyJGm9ePKuJvFxr4MQGLJYaNKJMKDWU=; b=iRqU0guTyu3CQhfD3uIcS7Foqs22SdyN9tvksg874UMRvGKXZ5mx7t8DbQs2jrvNmw 7hEyOvIBYptiMu2LZbw0/dY8oxLz1CBdEpE/DVCDxckkH/zJNAaQgRE45kZHHS7VziSL GJ1WPO6uye3GNRSpKFBzJifBNeNXE59M1ZMuRr2iLe8lKHnf9WjwxPfsYYsyyRgDAMJp PwZ/Mf5Ml+Y8SwZDW+REUV4m1xe4rJ1wkGrQePDLBpjsbbuSRzPV6GlQBljVSatv3mm/ dBMY77AQvag0u7yNFj+zV9gdZkqTG/cI1jyR1hnK/8E6HorFcxUkTlsyewXO69KfAVoF nLJQ== X-Gm-Message-State: AAQBX9cWbZJK8/8jLzAYjG65lhNa/f/pXARjeFyOiVUsTAR4hlRvOCdt lUxEffdq9dwM4rf54ESxRFDR5F6NI8w= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6902:1247:b0:a5f:0:bf12 with SMTP id t7-20020a056902124700b00a5f0000bf12mr3324492ybu.13.1679494343468; Wed, 22 Mar 2023 07:12:23 -0700 (PDT) Reply-To: Sean Christopherson Date: Wed, 22 Mar 2023 07:12:20 -0700 Mime-Version: 1.0 X-Mailer: git-send-email 2.40.0.rc2.332.ga46443480c-goog Message-ID: <20230322141220.2206241-1-seanjc@google.com> Subject: [PATCH] KVM: x86: Suppress pending MMIO write exits if emulator detects exception From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, zhangjianguo , syzbot+760a73552f47a8cd0fd9@syzkaller.appspotmail.com, syzbot+8accb43ddc6bd1f5713a@syzkaller.appspotmail.com X-Spam-Status: No, score=-7.7 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761078008547263647?= X-GMAIL-MSGID: =?utf-8?q?1761078008547263647?= Clear vcpu->mmio_needed when injecting an exception from the emulator to squash a (legitimate) warning about vcpu->mmio_needed being true at the start of KVM_RUN without a callback being registered to complete the userspace MMIO exit. Suppressing the MMIO write exit is inarguably wrong from an architectural perspective, but it is the least awful hack-a-fix due to shortcomings in KVM's uAPI, not to mention that KVM already suppresses MMIO writes in this scenario. Outside of REP string instructions, KVM doesn't provide a way to resume an instruction at the exact point where it was "interrupted" if said instruction partially completed before encountering an MMIO access. For MMIO reads, KVM immediately exits to userspace upon detecting MMIO as userspace provides the to-be-read value in a buffer, and so KVM can safely (more or less) restart the instruction from the beginning. When the emulator re-encounters the MMIO read, KVM will service the MMIO by getting the value from the buffer instead of exiting to userspace, i.e. KVM won't put the vCPU into an infinite loop. On an emulated MMIO write, KVM finishes the instruction before exiting to userspace, as exiting immediately would ultimately hang the vCPU due to the aforementioned shortcoming of KVM not being able to resume emulation in the middle of an instruction. For the vast majority of _emulated_ instructions, deferring the userspace exit doesn't cause problems as very few x86 instructions (again ignoring string operations) generate multiple writes. But for instructions that generate multiple writes, e.g. PUSHA (multiple pushes onto the stack), deferring the exit effectively results in only the final write triggering an exit to userspace. KVM does support multiple MMIO "fragments", but only for page splits; if an instruction performs multiple distinct MMIO writes, the number of fragments gets reset when the next MMIO write comes along and any previous MMIO writes are dropped. Circling back to the warning, if a deferred MMIO write coincides with an exception, e.g. in this case a #SS due to PUSHA underflowing the stack after queueing a write to an MMIO page on a previous push, KVM injects the exceptions and leaves the deferred MMIO pending without registering a callback, thus triggering the splat. Sweep the problem under the proverbial rug as dropping MMIO writes is not unique to the exception scenario (see above), i.e. instructions like PUSHA are fundamentally broken with respect to MMIO, and have been since KVM's inception. Reported-by: zhangjianguo Reported-by: syzbot+760a73552f47a8cd0fd9@syzkaller.appspotmail.com Reported-by: syzbot+8accb43ddc6bd1f5713a@syzkaller.appspotmail.com Signed-off-by: Sean Christopherson --- arch/x86/kvm/x86.c | 2 ++ 1 file changed, 2 insertions(+) base-commit: 45dd9bc75d9adc9483f0c7d662ba6e73ed698a0b diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index f706621c35b8..6a3e358a32a6 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -8881,6 +8881,8 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa, } if (ctxt->have_exception) { + WARN_ON_ONCE(vcpu->mmio_needed && !vcpu->mmio_is_write); + vcpu->mmio_needed = false; r = 1; inject_emulated_exception(vcpu); } else if (vcpu->arch.pio.count) {