Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp7692ybe; Thu, 12 Sep 2019 14:34:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqwyXjTZkAxMUIJXG6S3Q+QL+9ePW8NPcnJFXKnjkBm+QSoUcB/bBaVNz2bZe9le0yQ6UNcF X-Received: by 2002:a17:906:6c8:: with SMTP id v8mr36994ejb.252.1568324088589; Thu, 12 Sep 2019 14:34:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568324088; cv=none; d=google.com; s=arc-20160816; b=vc//ihs5zSNJMP7ZzbyAdB/0DNw2tArDrNfLM/2bhSdO4pJIeHqCTly0nYq+YJlgbC svfK/WyKPOUo9T1MpdnzX7XeLXmRK79hoq2BWnfGmTaaP1zVAtdh4OiaiQ+LuVxIsNhV JDTtv0cspf0aQIDZRfdiogfy74f97imP5WxuXWexUGxsis/1QPNV7qT066x7AULUkv3Z tVWXZhbGCT0SnQd11xEiL08LlycNdC/WYzhyaCRCphiKc3M6tZo4QD0fiGZuVDZe9Smb ymCjR+UHj2qmxHbr9TPjzELMq68nI1t8kqa/ccfwULPxlMPsUPsWMI/FHoOKQ7ywRF9S MivQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=zoH4QTE6JeRQ9cejfuBwTdDAfAuJXRi5JfhYPwN1PqU=; b=HzyIPZx8YIpqW3T3GD/JxRUH3IpSM54TjTIxq6CeuWd896YT/20cEc1DTzpzby3zQK Axpxn3TYwhkyDIpGTO/7kgT7x0qu2TWKa9qK/2vXTjo/9GUiWew8EJWQtdqbRTzjv3NT 8GQCLDcNRMwQGgVR39QQ5xZsLdvqZutWJsR5UsrYX3HLbfQWzHLg/3nlMBGiMp8bQTll u2Y4ijJEP4yFyp7Wd+2dZ/6nBzKGciFQLVVWGIcJ95WBFG80QIvKPkNsBzr6CbGUf8tj 4u2kCALn2y8p1Ij1PEhuO8kuAsLmPESpGDRNZ90rtnU/Gw1BGpV3XnLnN1J7/lpRgDy0 otYw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y50si17225773edd.237.2019.09.12.14.34.25; Thu, 12 Sep 2019 14:34:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730002AbfILQoZ (ORCPT + 99 others); Thu, 12 Sep 2019 12:44:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52882 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728983AbfILQoZ (ORCPT ); Thu, 12 Sep 2019 12:44:25 -0400 Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A8D3881DFF for ; Thu, 12 Sep 2019 16:44:24 +0000 (UTC) Received: by mail-wm1-f70.google.com with SMTP id 15so142878wmj.0 for ; Thu, 12 Sep 2019 09:44:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=zoH4QTE6JeRQ9cejfuBwTdDAfAuJXRi5JfhYPwN1PqU=; b=GZxmVzgAqPzrv6k+tGolWPqJQChBsiaoFBGQNWV5oT9t2k9hVBt3x2qtEIPkGDx/6H znluDo7iGIUhgH/pUaIC9KKf/7eIs4xYtXjBNBKsb49CLkIAzlw6I87KoWZe0Ned0eFS VREWXsZ7r8+dbm95ICPFRGWm3vGj3ieToWNDkIolHbBJYqDXqC+KeC1M8AavSYHjWiTm Y1zCTD6I5tt7LpDJ87PyCiNSzpyjc4vpIp/PC8u4hdeo3c7pkdEqYS619/YFwuWa1sEw Rlz2zk1UYA8hXf1BFmDJpLVryE2487SL8HUqPnH+sOJzCJ4/2wZV7CgqWz2mIM1NFziv nVZw== X-Gm-Message-State: APjAAAWRHxuecKK70vf2zpnsszJITVRlc1rezBAUsXMlS2ghqHmVNUqn LVOPbRp8oj5C8Y1Ls7Dd1LzBI7diuCeqjycCNZht6gXXIlyGDW5mqvVEgtYx1De5AAsESMGQ4Su 3NAj8iQIWLwsicYiEZ78VvPsm X-Received: by 2002:adf:e94f:: with SMTP id m15mr2619465wrn.225.1568306663101; Thu, 12 Sep 2019 09:44:23 -0700 (PDT) X-Received: by 2002:adf:e94f:: with SMTP id m15mr2619441wrn.225.1568306662883; Thu, 12 Sep 2019 09:44:22 -0700 (PDT) Received: from vitty.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id a190sm743531wme.8.2019.09.12.09.44.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Sep 2019 09:44:22 -0700 (PDT) From: Vitaly Kuznetsov To: Jim Mattson Cc: Fuqian Huang , Paolo Bonzini , Radim =?utf-8?B?S3LEjW3DocWZ?= , Sean Christopherson , Wanpeng Li , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H . Peter Anvin" , the arch/x86 maintainers , kvm list , LKML Subject: Re: [PATCH] KVM: x86: work around leak of uninitialized stack contents In-Reply-To: References: <20190912041817.23984-1-huangfq.daxian@gmail.com> <87tv9hew2k.fsf@vitty.brq.redhat.com> Date: Thu, 12 Sep 2019 18:44:21 +0200 Message-ID: <874l1hcvmi.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jim Mattson writes: > On Thu, Sep 12, 2019 at 1:51 AM Vitaly Kuznetsov wrote: >> >> Fuqian Huang writes: >> >> > Emulation of VMPTRST can incorrectly inject a page fault >> > when passed an operand that points to an MMIO address. >> > The page fault will use uninitialized kernel stack memory >> > as the CR2 and error code. >> > >> > The right behavior would be to abort the VM with a KVM_EXIT_INTERNAL_ERROR >> > exit to userspace; >> >> Hm, why so? KVM_EXIT_INTERNAL_ERROR is basically an error in KVM, this >> is not a proper reaction to a userspace-induced condition (or ever). > > This *is* an error in KVM. KVM should properly emulate the quadword > store to the emulated device. Doing anything else is just wrong. > > KVM_INTERNAL_ERROR is basically a cop-out for things that are hard. Yes, I way arguing with "the right behavior would be" in relation to KVM_INTERNAL_ERROR. > >> I also looked at VMPTRST's description in Intel's manual and I can't >> find and explicit limitation like "this must be normal memory". We're >> just supposed to inject #PF "If a page fault occurs in accessing the >> memory destination operand." >> >> In case it seems to be too cumbersome to handle VMPTRST to MMIO and we >> think that nobody should be doing that I'd rather prefer injecting #GP. > > That is not the architected behavior at all. Now you're just making > things up! True and I'm not against KVM_INTERNAL_ERROR as an iterim solution if it comes with a comment explaining why we're 'admitting defeat' here. -- Vitaly