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 1A0A7C433FE for ; Wed, 19 Jan 2022 00:07:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344212AbiASAHv (ORCPT ); Tue, 18 Jan 2022 19:07:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48434 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234548AbiASAHu (ORCPT ); Tue, 18 Jan 2022 19:07:50 -0500 Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 03F68C061574 for ; Tue, 18 Jan 2022 16:07:50 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id s15so878239pfw.1 for ; Tue, 18 Jan 2022 16:07:49 -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:in-reply-to; bh=vAxUGBdxlByR43mCEdZpVjv0Zz9WIa7OMWfFPmEbMTk=; b=qBXZz3eV8Rov2cm1W3wCt0Wf5F4ztIaFimefC7TG1Rnsledjc6d3hrI2tmNnsnk5ds 46g8Nl6YqHfQImsWCVu9ZE/+2+quk+HTgCOPTzKEjkoXOnZ/ShhHtxfonlnThm8Ihtq8 PmKepSxLMvuRUptYU7UdU5+d1atrnaYttTrpddGtCSVLAjHnyElfzJcEzcnQLw3PQKqf gWNb3gFBRJpOBXG7e758cFocItjh3GRGCOt2WYq0JFuxKSF1WgHrGbinNWK/SjAdgKbF RVY5+MHZdltx0CezKaIfkDI54ms+HBx7lceqPVX8LfnWyUumSYbbMdxiDhBKyxUT9p1W k7lA== 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:in-reply-to; bh=vAxUGBdxlByR43mCEdZpVjv0Zz9WIa7OMWfFPmEbMTk=; b=B+RgDwg0e4pcVnDjZAppsLcgzxI8/vUiG/gPGUbt4/zmjxoFZA0bWe/FGiLrK3t8QS wSFuG4yp/Vxn9D7nmV6AY8D0jpSAdvuU5MKCyi+bKWMqSSWsnHaL3hPo/FUf3ckEP4A3 BUWOZI46PnKskRfoGj8Rh1cskF5A8AJh/GtjTzX78mbtXH5St7fb5z0dLcaeouD9iNLF HeM3yMzhNvSWy5vZCTs3wYNGynDXvOo4PovenCRl881HIrjfFI/L8oXtwpCkads9askZ Hn+jGA74auIGoMmm7+29Jb9y5CmT9B9JGL36O5NHDrMrDV51KkYtDpI+kRllb+ookKhu +61A== X-Gm-Message-State: AOAM532X61Mb0d7Dy8QqiOSPHDRsbpH9QEcUOcRc3Q/fbHVsnh7Y7ICL IInkITZsoFR5I12h2H8EWetkIw== X-Google-Smtp-Source: ABdhPJxPq8SLTjE6n9JfYMFuQM1fFo8QhRlyyDWq9vPyshu5dZQT3oKCJx+oL4oaffzzN4FevbTMSQ== X-Received: by 2002:a63:d417:: with SMTP id a23mr9394020pgh.297.1642550869199; Tue, 18 Jan 2022 16:07:49 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id n11sm13527252pgm.1.2022.01.18.16.07.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Jan 2022 16:07:48 -0800 (PST) Date: Wed, 19 Jan 2022 00:07:44 +0000 From: Sean Christopherson To: Reiji Watanabe Cc: Raghavendra Rao Ananta , kvm@vger.kernel.org, Marc Zyngier , Peter Shier , linux-kernel@vger.kernel.org, Catalin Marinas , Paolo Bonzini , Will Deacon , kvmarm@lists.cs.columbia.edu, Linux ARM , Jim Mattson Subject: Re: [RFC PATCH v3 01/11] KVM: Capture VM start Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 14, 2022, Reiji Watanabe wrote: > The restriction, with which KVM doesn't need to worry about the changes > in the registers after KVM_RUN, could potentially protect or be useful > to protect KVM and simplify future changes/maintenance of the KVM codes > that consumes the values. That sort of protection is definitely welcome, the previously mentioned CPUID mess on x86 would have benefit greatly by KVM being restrictive in the past. That said, hooking KVM_RUN is likely the wrong way to go about implementing any restrictions. Running a vCPU is where much of the vCPU's state is explicitly consumed, but it's all too easy for KVM to implicity/indirectly consume state via a different ioctl(), e.g. if there are side effects that are visible in other registers, than an update can also be visible to userspace via KVM_{G,S}ET_{S,}REGS, at which point disallowing modifying state after KVM_RUN but not after reading/writing regs is arbitrary and inconsitent. If possible, preventing modification if kvm->created_vcpus > 0 is ideal as it's a relatively common pattern in KVM, and provides a clear boundary to userpace regarding what is/isn't allowed.