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 BB47CC433FE for ; Thu, 20 Jan 2022 00:27:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357782AbiATA1X (ORCPT ); Wed, 19 Jan 2022 19:27:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40002 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231437AbiATA1U (ORCPT ); Wed, 19 Jan 2022 19:27:20 -0500 Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B035FC06161C for ; Wed, 19 Jan 2022 16:27:20 -0800 (PST) Received: by mail-pj1-x1034.google.com with SMTP id s2-20020a17090ad48200b001b501977b23so3286323pju.2 for ; Wed, 19 Jan 2022 16:27:20 -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=+TqAt14XKXCbtB/P6ewZv6dez1U9WqxQBNJ+sItXmlI=; b=F/r6jm4JzyNVaU7DF6e9U4M2zV1h4k4Mrg4VYBW7l2IN1j8EcwrQiXOcu6Gvnk3jmR Zm2RatSb4zvpG74iCIhDtzCg6rvMo+nBURyCB3QB1+fQAnKweumNAkvx1I0SD+PE25XA 5QD9kMNy3iNJXNSIyNTNzCWpvVz749GYxa3+R3vpzTKty2zLTAegEINhm195SOL+mC+y tkU6I6kM6Ccpiy6EtPro96tevnIfYb9L/UeN5LaOpwbNxRGL8uOeJwIGfpi1eufa0kdF F7O2Ur+Xe5ycOLIpqYgay4HF0msKYazYuSjCZjRzZrXKKAgO4PZHEWZ7mwcdTem4h2oT zocg== 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=+TqAt14XKXCbtB/P6ewZv6dez1U9WqxQBNJ+sItXmlI=; b=vuK/ybU4mOHkhgLBZf3tpa8mSQtcHBYbK7UDUXRpQENqPpIIl13bwjHbKqpPpKu/ei 5jRYtuyvXClA4ISfDbuvvGpo2ggdHHEi7bbptS7cYNQ2LCDE0xTPBp8lx+c0fsmPtOFB TJrIVBXjDD9LLzTr+FwLsoDylhW+BEqT2WC8msDhh44HQU7bHFpc89oNpj3+RxcYlxM7 SCKYUG3WkoKWwdmru05M2sXurgWfBOImQv15jGNh5xNih3OZBz+EqC4JwD1HljCXnKXe J9m1GHdQmJo9n+PhPVAUv9uA8vjLmXBNhF5kBXf2gTFEWzqRqI4dUktE4olCPMEj1yV+ pSgg== X-Gm-Message-State: AOAM530KAkb8GqjYfBSMp1iHauzu12QdXlw9kSSNT1vxMJfZFsjThmGz q/V94BXhnCeD75+JAnJu/fZdVA== X-Google-Smtp-Source: ABdhPJy8eb351Wq5iEXEb6Pkw/V9Y3ntyEY4dpEYnYofdfrP1ruzhmhasshPA0tIWyfCz/62Czq8cA== X-Received: by 2002:a17:90a:5d07:: with SMTP id s7mr7432257pji.226.1642638440008; Wed, 19 Jan 2022 16:27:20 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id a3sm706367pfo.163.2022.01.19.16.27.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Jan 2022 16:27:19 -0800 (PST) Date: Thu, 20 Jan 2022 00:27:16 +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 Tue, Jan 18, 2022, Reiji Watanabe wrote: > On Tue, Jan 18, 2022 at 4:07 PM Sean Christopherson wrote: > > > > 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. > > Thank you for your comments ! > I think I understand your concern, and that's a great point. > That's not the case for those pseudo registers though at least for now :) > BTW, is this concern specific to hooking KVM_RUN ? (Wouldn't it be the > same for the option with "if kvm->created_vcpus > 0" ?) Not really? The goal with created_vcpus is to avoid having inconsistent state in "struct kvm_vcpu" with respect to the VM as whole. "struct kvm" obvioulsy can't be inconsistent with itself, e.g. even if userspace consumes some side effect, that's simply "the state". Did that make sense? Hard to explain in writing :-) > > 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. > > Yes, I agree that would be better in general. For (pseudo) registers, What exactly are these pseudo registers? If it's something that's an immutable property of the (virtual) system, then it might make sense to use a separate, non-vCPU mechanism for setting/getting their values. Then you can easily restrict the to pre-created_vcpus, e.g. see x86's KVM_SET_IDENTITY_MAP_ADDR. > I would think preventing modification if kvm->created_vcpus > 0 might > not be a very good option for KVM/ARM though considering usage of > KVM_GET_REG_LIST and KVM_{G,S}ET_ONE_REG. 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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id CE108C4332F for ; Thu, 20 Jan 2022 00:27:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 137C549F30; Wed, 19 Jan 2022 19:27:25 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVKlnJWzD-e3; Wed, 19 Jan 2022 19:27:23 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 9628149F13; Wed, 19 Jan 2022 19:27:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id B0C4E49F0A for ; Wed, 19 Jan 2022 19:27:22 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgvAFBt-fTcl for ; Wed, 19 Jan 2022 19:27:21 -0500 (EST) Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 3525C49F04 for ; Wed, 19 Jan 2022 19:27:21 -0500 (EST) Received: by mail-pl1-f176.google.com with SMTP id f13so3803887plg.0 for ; Wed, 19 Jan 2022 16:27:21 -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=+TqAt14XKXCbtB/P6ewZv6dez1U9WqxQBNJ+sItXmlI=; b=F/r6jm4JzyNVaU7DF6e9U4M2zV1h4k4Mrg4VYBW7l2IN1j8EcwrQiXOcu6Gvnk3jmR Zm2RatSb4zvpG74iCIhDtzCg6rvMo+nBURyCB3QB1+fQAnKweumNAkvx1I0SD+PE25XA 5QD9kMNy3iNJXNSIyNTNzCWpvVz749GYxa3+R3vpzTKty2zLTAegEINhm195SOL+mC+y tkU6I6kM6Ccpiy6EtPro96tevnIfYb9L/UeN5LaOpwbNxRGL8uOeJwIGfpi1eufa0kdF F7O2Ur+Xe5ycOLIpqYgay4HF0msKYazYuSjCZjRzZrXKKAgO4PZHEWZ7mwcdTem4h2oT zocg== 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=+TqAt14XKXCbtB/P6ewZv6dez1U9WqxQBNJ+sItXmlI=; b=1SBfmdH7U0bBPIRpK2acZyDVXLhfwZLQMlzpQ4uhg/VEPx8j7yntXKrdo1NCtNRZWH FOO4FWGxsf+7j1K1gNmC4nPMYk6Q1LXqdc9UNOSXL2VV15Qfik04BCeOqfJqSfFA7bAE e4cjoJZmkkT8Y1ai4g7lxfMRyGz+C69Nao5vvXb7Ittomcn9KuxNehaEZd+EskGrYJMS NFmW/6EMcK4weIAPDg9kVu5jvPay/tnyYIDT/sCrXNCu24+aq1pyzo3p+M0sTAUKmCNr 7x6yslywgGPB2/Vr45jCbO7GOqSvDwbE3I8EsnEw+zsPTlr6xLn38uMkk+JNbkOZUWAw 3g1g== X-Gm-Message-State: AOAM533qdFE6E/BZ/cpgFlmRcVxfoSa3D6Fiv7tVHWffIh3Hq7K3A8Ra E0stgoeWxEi8p0TEKQWzk46lWA== X-Google-Smtp-Source: ABdhPJy8eb351Wq5iEXEb6Pkw/V9Y3ntyEY4dpEYnYofdfrP1ruzhmhasshPA0tIWyfCz/62Czq8cA== X-Received: by 2002:a17:90a:5d07:: with SMTP id s7mr7432257pji.226.1642638440008; Wed, 19 Jan 2022 16:27:20 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id a3sm706367pfo.163.2022.01.19.16.27.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Jan 2022 16:27:19 -0800 (PST) Date: Thu, 20 Jan 2022 00:27:16 +0000 From: Sean Christopherson To: Reiji Watanabe Subject: Re: [RFC PATCH v3 01/11] KVM: Capture VM start Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: kvm@vger.kernel.org, Catalin Marinas , Peter Shier , linux-kernel@vger.kernel.org, Marc Zyngier , Paolo Bonzini , Will Deacon , kvmarm@lists.cs.columbia.edu, Linux ARM , Jim Mattson X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Tue, Jan 18, 2022, Reiji Watanabe wrote: > On Tue, Jan 18, 2022 at 4:07 PM Sean Christopherson wrote: > > > > 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. > > Thank you for your comments ! > I think I understand your concern, and that's a great point. > That's not the case for those pseudo registers though at least for now :) > BTW, is this concern specific to hooking KVM_RUN ? (Wouldn't it be the > same for the option with "if kvm->created_vcpus > 0" ?) Not really? The goal with created_vcpus is to avoid having inconsistent state in "struct kvm_vcpu" with respect to the VM as whole. "struct kvm" obvioulsy can't be inconsistent with itself, e.g. even if userspace consumes some side effect, that's simply "the state". Did that make sense? Hard to explain in writing :-) > > 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. > > Yes, I agree that would be better in general. For (pseudo) registers, What exactly are these pseudo registers? If it's something that's an immutable property of the (virtual) system, then it might make sense to use a separate, non-vCPU mechanism for setting/getting their values. Then you can easily restrict the to pre-created_vcpus, e.g. see x86's KVM_SET_IDENTITY_MAP_ADDR. > I would think preventing modification if kvm->created_vcpus > 0 might > not be a very good option for KVM/ARM though considering usage of > KVM_GET_REG_LIST and KVM_{G,S}ET_ONE_REG. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AC5B0C433EF for ; Thu, 20 Jan 2022 00:28:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=4l/pkTNxFxWccpEMu9x39A8ss3wtAP8+JfJU8J9561A=; b=IPuRs80cbgo303 fBuxmZyz+CVwoQUAx9+uFsSAwxOfHlVt3nSRnM1hhAmpU8b+7OQyMVKI1y5sVdonsDlKX4vZ2Oxd1 Imel/24bMcMR6H0NVH8iVwf55Z7RsQ3o5o0ZqLlAaZWL58zH/AMDNFq+kP64PIq/+6BjJQhJzj3+G 808pb581cke/iuIawMD69ix1H4SiFMcRTxiQLDXyUekiPgbiW2s5CTXi14JZhdpzowU5GXU8Y2i4+ 5w8tsyrnRU1XP3SU7kdHlFJKV5ioGoSQWA0nKFoaVKnXnX28SI4hQyrBAfKsFS8Hc8xgfU7K8hQvZ nEmr1+8psqZZm6oMZbRQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nALIW-007zcy-SH; Thu, 20 Jan 2022 00:27:29 +0000 Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nALIT-007zZn-Vo for linux-arm-kernel@lists.infradead.org; Thu, 20 Jan 2022 00:27:27 +0000 Received: by mail-pj1-x1029.google.com with SMTP id w12-20020a17090a528c00b001b276aa3aabso8334848pjh.0 for ; Wed, 19 Jan 2022 16:27:20 -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=+TqAt14XKXCbtB/P6ewZv6dez1U9WqxQBNJ+sItXmlI=; b=F/r6jm4JzyNVaU7DF6e9U4M2zV1h4k4Mrg4VYBW7l2IN1j8EcwrQiXOcu6Gvnk3jmR Zm2RatSb4zvpG74iCIhDtzCg6rvMo+nBURyCB3QB1+fQAnKweumNAkvx1I0SD+PE25XA 5QD9kMNy3iNJXNSIyNTNzCWpvVz749GYxa3+R3vpzTKty2zLTAegEINhm195SOL+mC+y tkU6I6kM6Ccpiy6EtPro96tevnIfYb9L/UeN5LaOpwbNxRGL8uOeJwIGfpi1eufa0kdF F7O2Ur+Xe5ycOLIpqYgay4HF0msKYazYuSjCZjRzZrXKKAgO4PZHEWZ7mwcdTem4h2oT zocg== 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=+TqAt14XKXCbtB/P6ewZv6dez1U9WqxQBNJ+sItXmlI=; b=VggMxXboggEYGProYPI+T33PUjqk/c0HbvsHH5oeghnm2WD9hGJqEnFaVI4H+K1W5I FDDPYlKuO5ZywuwhdYcKeOTuSdX70dOZC83DSvAO1cOidI2V3xrs+ByUImxUsFSiTfMR 4cv8A3uortmkRRhFcaukkJizva+5IRMFJw7FfilJy50E13IIJpm+ebaD7kFWpSOe6OCI fRgklASqvjzWc3GfiMPAItJkkqq6Q8XdWUb0HDp54XIu+/o6Kxt+WWCjliKR/Dwzoxpb kxzGasH86LrnM2xOrR/kvMZxmEeS1ACvIPg+eZ+azLpmjvBYYEQfgtH9dMLkjOoIUWvb d7Gg== X-Gm-Message-State: AOAM530ti3aVsY7TtUfeyDyvj95ikC1+tOUL3GOkgIUvdqaKHbd51/wT GxdcNyT/WdLdEyIYMWSEs5/nXQ== X-Google-Smtp-Source: ABdhPJy8eb351Wq5iEXEb6Pkw/V9Y3ntyEY4dpEYnYofdfrP1ruzhmhasshPA0tIWyfCz/62Czq8cA== X-Received: by 2002:a17:90a:5d07:: with SMTP id s7mr7432257pji.226.1642638440008; Wed, 19 Jan 2022 16:27:20 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id a3sm706367pfo.163.2022.01.19.16.27.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Jan 2022 16:27:19 -0800 (PST) Date: Thu, 20 Jan 2022 00:27:16 +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-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220119_162726_058469_B1E733A0 X-CRM114-Status: GOOD ( 31.25 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jan 18, 2022, Reiji Watanabe wrote: > On Tue, Jan 18, 2022 at 4:07 PM Sean Christopherson wrote: > > > > 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. > > Thank you for your comments ! > I think I understand your concern, and that's a great point. > That's not the case for those pseudo registers though at least for now :) > BTW, is this concern specific to hooking KVM_RUN ? (Wouldn't it be the > same for the option with "if kvm->created_vcpus > 0" ?) Not really? The goal with created_vcpus is to avoid having inconsistent state in "struct kvm_vcpu" with respect to the VM as whole. "struct kvm" obvioulsy can't be inconsistent with itself, e.g. even if userspace consumes some side effect, that's simply "the state". Did that make sense? Hard to explain in writing :-) > > 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. > > Yes, I agree that would be better in general. For (pseudo) registers, What exactly are these pseudo registers? If it's something that's an immutable property of the (virtual) system, then it might make sense to use a separate, non-vCPU mechanism for setting/getting their values. Then you can easily restrict the to pre-created_vcpus, e.g. see x86's KVM_SET_IDENTITY_MAP_ADDR. > I would think preventing modification if kvm->created_vcpus > 0 might > not be a very good option for KVM/ARM though considering usage of > KVM_GET_REG_LIST and KVM_{G,S}ET_ONE_REG. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel