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 17AC4C433F5 for ; Tue, 11 Jan 2022 19:18:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345658AbiAKTSY (ORCPT ); Tue, 11 Jan 2022 14:18:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350698AbiAKTRg (ORCPT ); Tue, 11 Jan 2022 14:17:36 -0500 Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 28231C06118C for ; Tue, 11 Jan 2022 11:16:59 -0800 (PST) Received: by mail-ot1-x334.google.com with SMTP id a23-20020a9d4717000000b0056c15d6d0caso19673253otf.12 for ; Tue, 11 Jan 2022 11:16:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RmmeEOXgL4aczt2lYfVEJ81JJyR5GHuXnUEqtqtBYAw=; b=cOATJM7qKaMwa1rfMreaSBRrwDDzMO7PjOtbZd5NEoxEnpoVYSyEoZ9YYXqeYIXSvr YE9v8N/iag490QDHMRj+L/DdGLjpFJHDqQCT7vnsL3SeJdwkX63Af178WulVTiUohxbi 2Z/g/UTUnmDWrvpF1A4BuycMUQiQMZtfEfDMEJMhly8ysY21Lwy1FYkVyAAHc2Y+CloD QUqxx8+pjJdctbF3pQ+CoqO2LSEEj2OAsTt02lMfMbyq/L2h4o6KshlrJhMnTMxz7HRI kj1j8PJ6vmHhfhTs5wV82Z3hYb9FrcuJ2q8JzsdRPEiJYoahPTsWOV6v37b2pmdg3f9Q Qtpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RmmeEOXgL4aczt2lYfVEJ81JJyR5GHuXnUEqtqtBYAw=; b=blyBUQt8NGLuT2Xa991X4XzJxvWkWGOexyfeGvVHZLyfJW86IdMWdiAwlgvgwKbV5U XPPwgijTSrj3Skmit0V3LmH1RfgOkf1qDPB6CiolujoJRStcM31sx7zyco2uBT5IJ6fC GNaocIvbKZ2WMQtfHiMds6k7ZYQJvm7LzuL8FJX+ntiQnKXac7hfwJ8uCkAiOa3R42a+ SGPj7NT8ZOKmLhVMkiR1VaVg1HaFLTgrs62mg/MZM2LJmGZuUUDL4bp3gaQ8JZTDkPa4 yibDAUYWJDOqbRSGwn5TkRduNLe3FsEY+UX4hgx9cycbQQvkajARdijs5DM24jDRqIRU lF1A== X-Gm-Message-State: AOAM5338tkzvFffLcqPlR3mjfIog50KoceXzBiIqy978YOjBAV4fbBqw Y05FrPYlJN4sbvG0hWhTWlYGDeVYHK0rQmm3ecd5Sg== X-Google-Smtp-Source: ABdhPJyFhnhDMW2ISK4zn+lMszvCQjj7MkaLiyC7O4OUsyaW0HdldRqbQFmZ06I5CZ/gdojGHnnTpqjIXgdkiahuGYk= X-Received: by 2002:a05:6830:441f:: with SMTP id q31mr4578699otv.14.1641928618059; Tue, 11 Jan 2022 11:16:58 -0800 (PST) MIME-Version: 1.0 References: <20220104194918.373612-1-rananta@google.com> <20220104194918.373612-2-rananta@google.com> In-Reply-To: From: Jim Mattson Date: Tue, 11 Jan 2022 11:16:46 -0800 Message-ID: Subject: Re: [RFC PATCH v3 01/11] KVM: Capture VM start To: Raghavendra Rao Ananta Cc: Reiji Watanabe , Marc Zyngier , Andrew Jones , James Morse , Alexandru Elisei , Suzuki K Poulose , Paolo Bonzini , Catalin Marinas , Will Deacon , Peter Shier , Ricardo Koller , Oliver Upton , Jing Zhang , Linux ARM , kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 11, 2022 at 10:52 AM Raghavendra Rao Ananta wrote: > > On Mon, Jan 10, 2022 at 3:57 PM Jim Mattson wrote: > > > > On Mon, Jan 10, 2022 at 3:07 PM Raghavendra Rao Ananta > > wrote: > > > > > > On Fri, Jan 7, 2022 at 4:05 PM Jim Mattson wrote: > > > > > > > > On Fri, Jan 7, 2022 at 3:43 PM Raghavendra Rao Ananta > > > > wrote: > > > > > > > > > > Hi Reiji, > > > > > > > > > > On Thu, Jan 6, 2022 at 10:07 PM Reiji Watanabe wrote: > > > > > > > > > > > > Hi Raghu, > > > > > > > > > > > > On Tue, Jan 4, 2022 at 11:49 AM Raghavendra Rao Ananta > > > > > > wrote: > > > > > > > > > > > > > > Capture the start of the KVM VM, which is basically the > > > > > > > start of any vCPU run. This state of the VM is helpful > > > > > > > in the upcoming patches to prevent user-space from > > > > > > > configuring certain VM features after the VM has started > > > > > > > running. > > > > > > > > What about live migration, where the VM has already technically been > > > > started before the first call to KVM_RUN? > > > > > > My understanding is that a new 'struct kvm' is created on the target > > > machine and this flag should be reset, which would allow the VMM to > > > restore the firmware registers. However, we would be running KVM_RUN > > > for the first time on the target machine, thus setting the flag. > > > So, you are right; It's more of a resume operation from the guest's > > > point of view. I guess the name of the variable is what's confusing > > > here. > > > > I was actually thinking that live migration gives userspace an easy > > way to circumvent your restriction. You said, "This state of the VM is > > helpful in the upcoming patches to prevent user-space from configuring > > certain VM features after the VM has started running." However, if you > > don't ensure that these VM features are configured the same way on the > > target machine as they were on the source machine, you have not > > actually accomplished your stated goal. > > > Isn't that up to the VMM to save/restore and validate the registers > across migrations? Yes, just as it is up to userspace not to make bad configuration changes after the first VMRUN. > Perhaps I have to re-word my intentions for the patch- userspace > should be able to configure the registers before issuing the first > KVM_RUN. Perhaps it would help if you explained *why* you are doing this. It sounds like you are either trying to protect against a malicious userspace, or you are trying to keep userspace from doing something stupid. In general, kvm only enforces constraints that are necessary to protect the host. If that's what you're doing, I don't understand why live migration doesn't provide an end-run around your protections. 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 267DEC433EF for ; Tue, 11 Jan 2022 19:18:19 +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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=IceXn+jY23fdvp2rvFkOtn6p8Dma+H2MEGwc0pu3o5Y=; b=wYJw1mRsl0oDha Q96ilct6oU2FKv4fO0K92dZLbmF8INdG0EE1ffBxN3w6Pd68e/wJkDruOawz8SCLGl4pmCHiheJfW V2+NacUOazomz+lyzh07UQns9TjkaMOleOnwksOZPH50zbdkyf4FqZC5oKXw4dUxvvNiSai0Epm+k CFC9HTIaGOysv6aLmIuqYQl+cRyJemT6szffuS3dgma8UINfXgpGqAHwotbkirBV0sbusws+PMPWe 2WxoX1zJpbqN/sUYEzdaq3+VkauI76WzxINunV0kqVrwyU3Y051pGpIg9oIuqCa/nT9KUrkeTkhUZ hDoPAr9xI3hGTfg4NHJg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n7Mdi-00HPSa-W9; Tue, 11 Jan 2022 19:17:03 +0000 Received: from mail-ot1-x32d.google.com ([2607:f8b0:4864:20::32d]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n7Mdf-00HPQL-Lk for linux-arm-kernel@lists.infradead.org; Tue, 11 Jan 2022 19:17:01 +0000 Received: by mail-ot1-x32d.google.com with SMTP id t6-20020a9d7746000000b005917e6b96ffso1860452otl.7 for ; Tue, 11 Jan 2022 11:16:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RmmeEOXgL4aczt2lYfVEJ81JJyR5GHuXnUEqtqtBYAw=; b=cOATJM7qKaMwa1rfMreaSBRrwDDzMO7PjOtbZd5NEoxEnpoVYSyEoZ9YYXqeYIXSvr YE9v8N/iag490QDHMRj+L/DdGLjpFJHDqQCT7vnsL3SeJdwkX63Af178WulVTiUohxbi 2Z/g/UTUnmDWrvpF1A4BuycMUQiQMZtfEfDMEJMhly8ysY21Lwy1FYkVyAAHc2Y+CloD QUqxx8+pjJdctbF3pQ+CoqO2LSEEj2OAsTt02lMfMbyq/L2h4o6KshlrJhMnTMxz7HRI kj1j8PJ6vmHhfhTs5wV82Z3hYb9FrcuJ2q8JzsdRPEiJYoahPTsWOV6v37b2pmdg3f9Q Qtpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RmmeEOXgL4aczt2lYfVEJ81JJyR5GHuXnUEqtqtBYAw=; b=C+QTmTeK6Tqrn3qSWGrZ33rj2tbHCtPNUUfRMPsJAGGTQCkVoqMJ5V3eZsm9d1gU6K HhXU88lCiUqZNjyRsycFuPR18Yqe5LaLlL7V52VolKjlKlZ+o41ik/P/il4Rv25KIz2n DpkR1FkNlL3ItJGu06gOpGWdFDoAvHmUkyUs8ColkwZvOrH1D9lqK+EEwcMd+doD0zlL gdQU5gyz1szXmgRBZKY6xqHez6IELHgsgwhS5q2i3tmR2Bt/HcN59UTyA/luUDgCOT6e xLKXAmmBTV1Z8mI5doA6uMlA884EPxMpu7ALnrhR2OOb+xIHaq89ZFqs7pzlJJOTJpYb LzGQ== X-Gm-Message-State: AOAM5320pgabMZZZ1/KB3pirpqY0EEIr7+JUfYozrBn9L4+xkUOhmoQg Z9mMmsgeGHEebY5fkkb2IX+TlPSKp1xEf1TwQzF9aA== X-Google-Smtp-Source: ABdhPJyFhnhDMW2ISK4zn+lMszvCQjj7MkaLiyC7O4OUsyaW0HdldRqbQFmZ06I5CZ/gdojGHnnTpqjIXgdkiahuGYk= X-Received: by 2002:a05:6830:441f:: with SMTP id q31mr4578699otv.14.1641928618059; Tue, 11 Jan 2022 11:16:58 -0800 (PST) MIME-Version: 1.0 References: <20220104194918.373612-1-rananta@google.com> <20220104194918.373612-2-rananta@google.com> In-Reply-To: From: Jim Mattson Date: Tue, 11 Jan 2022 11:16:46 -0800 Message-ID: Subject: Re: [RFC PATCH v3 01/11] KVM: Capture VM start To: Raghavendra Rao Ananta Cc: Reiji Watanabe , Marc Zyngier , Andrew Jones , James Morse , Alexandru Elisei , Suzuki K Poulose , Paolo Bonzini , Catalin Marinas , Will Deacon , Peter Shier , Ricardo Koller , Oliver Upton , Jing Zhang , Linux ARM , kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, kvm@vger.kernel.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220111_111659_757769_79F01046 X-CRM114-Status: GOOD ( 29.81 ) 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 11, 2022 at 10:52 AM Raghavendra Rao Ananta wrote: > > On Mon, Jan 10, 2022 at 3:57 PM Jim Mattson wrote: > > > > On Mon, Jan 10, 2022 at 3:07 PM Raghavendra Rao Ananta > > wrote: > > > > > > On Fri, Jan 7, 2022 at 4:05 PM Jim Mattson wrote: > > > > > > > > On Fri, Jan 7, 2022 at 3:43 PM Raghavendra Rao Ananta > > > > wrote: > > > > > > > > > > Hi Reiji, > > > > > > > > > > On Thu, Jan 6, 2022 at 10:07 PM Reiji Watanabe wrote: > > > > > > > > > > > > Hi Raghu, > > > > > > > > > > > > On Tue, Jan 4, 2022 at 11:49 AM Raghavendra Rao Ananta > > > > > > wrote: > > > > > > > > > > > > > > Capture the start of the KVM VM, which is basically the > > > > > > > start of any vCPU run. This state of the VM is helpful > > > > > > > in the upcoming patches to prevent user-space from > > > > > > > configuring certain VM features after the VM has started > > > > > > > running. > > > > > > > > What about live migration, where the VM has already technically been > > > > started before the first call to KVM_RUN? > > > > > > My understanding is that a new 'struct kvm' is created on the target > > > machine and this flag should be reset, which would allow the VMM to > > > restore the firmware registers. However, we would be running KVM_RUN > > > for the first time on the target machine, thus setting the flag. > > > So, you are right; It's more of a resume operation from the guest's > > > point of view. I guess the name of the variable is what's confusing > > > here. > > > > I was actually thinking that live migration gives userspace an easy > > way to circumvent your restriction. You said, "This state of the VM is > > helpful in the upcoming patches to prevent user-space from configuring > > certain VM features after the VM has started running." However, if you > > don't ensure that these VM features are configured the same way on the > > target machine as they were on the source machine, you have not > > actually accomplished your stated goal. > > > Isn't that up to the VMM to save/restore and validate the registers > across migrations? Yes, just as it is up to userspace not to make bad configuration changes after the first VMRUN. > Perhaps I have to re-word my intentions for the patch- userspace > should be able to configure the registers before issuing the first > KVM_RUN. Perhaps it would help if you explained *why* you are doing this. It sounds like you are either trying to protect against a malicious userspace, or you are trying to keep userspace from doing something stupid. In general, kvm only enforces constraints that are necessary to protect the host. If that's what you're doing, I don't understand why live migration doesn't provide an end-run around your protections. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 7DFD3C433F5 for ; Wed, 12 Jan 2022 11:18:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id E40594B25D; Wed, 12 Jan 2022 06:18:14 -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 tgI4czHi6w+u; Wed, 12 Jan 2022 06:18:13 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id BA6E94B1F3; Wed, 12 Jan 2022 06:18:13 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 3F2654B1E7 for ; Tue, 11 Jan 2022 14:17:00 -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 nWbqwwU9L7YK for ; Tue, 11 Jan 2022 14:16:59 -0500 (EST) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 2B1974B161 for ; Tue, 11 Jan 2022 14:16:59 -0500 (EST) Received: by mail-ot1-f41.google.com with SMTP id r7-20020a05683001c700b005906f5b0969so19758768ota.5 for ; Tue, 11 Jan 2022 11:16:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RmmeEOXgL4aczt2lYfVEJ81JJyR5GHuXnUEqtqtBYAw=; b=cOATJM7qKaMwa1rfMreaSBRrwDDzMO7PjOtbZd5NEoxEnpoVYSyEoZ9YYXqeYIXSvr YE9v8N/iag490QDHMRj+L/DdGLjpFJHDqQCT7vnsL3SeJdwkX63Af178WulVTiUohxbi 2Z/g/UTUnmDWrvpF1A4BuycMUQiQMZtfEfDMEJMhly8ysY21Lwy1FYkVyAAHc2Y+CloD QUqxx8+pjJdctbF3pQ+CoqO2LSEEj2OAsTt02lMfMbyq/L2h4o6KshlrJhMnTMxz7HRI kj1j8PJ6vmHhfhTs5wV82Z3hYb9FrcuJ2q8JzsdRPEiJYoahPTsWOV6v37b2pmdg3f9Q Qtpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RmmeEOXgL4aczt2lYfVEJ81JJyR5GHuXnUEqtqtBYAw=; b=NdMxHU69EeiykVfKTUbh+BPOxvn1KQk6GWHLBNyxXTveRaFrVA9teJx99OHK5bZQ9m VUGXqHYUVRDcNYfhxMvy1LMxagNcX54cMQdnAs1hqWI70kCq7E7Kn67gIKnjkFOvm4qa Nnzmw6+lpoatmO/48UmCvnO1ZcUUY0JqdLcN9tId2HJCR+stMDsfM7f7Tp79/eN4G/wW RSD+uTs3Wbr95r6vFZpVlZy+r+pUigOePwquauybqAYuu7A4wQxMNAot/P0Yvm1a+Hmq +IFgcqf7yZ2IS15I8NJHCUV8RoaKuSjw+NbsLZo6gAxiVCjEjWTtfSOU5N1qwOjdWEPs l0Tg== X-Gm-Message-State: AOAM531DF3f8JE5jHdHTojSH5Hdsj5G0ldddBifuM9pNIZLriC6LaGtn GuGdVAOW+3xYYrdynKo1df+3NeNUrTQUTsMF4qbknw== X-Google-Smtp-Source: ABdhPJyFhnhDMW2ISK4zn+lMszvCQjj7MkaLiyC7O4OUsyaW0HdldRqbQFmZ06I5CZ/gdojGHnnTpqjIXgdkiahuGYk= X-Received: by 2002:a05:6830:441f:: with SMTP id q31mr4578699otv.14.1641928618059; Tue, 11 Jan 2022 11:16:58 -0800 (PST) MIME-Version: 1.0 References: <20220104194918.373612-1-rananta@google.com> <20220104194918.373612-2-rananta@google.com> In-Reply-To: From: Jim Mattson Date: Tue, 11 Jan 2022 11:16:46 -0800 Message-ID: Subject: Re: [RFC PATCH v3 01/11] KVM: Capture VM start To: Raghavendra Rao Ananta X-Mailman-Approved-At: Wed, 12 Jan 2022 06:18:12 -0500 Cc: kvm@vger.kernel.org, Will Deacon , Marc Zyngier , Peter Shier , linux-kernel@vger.kernel.org, Catalin Marinas , Paolo Bonzini , kvmarm@lists.cs.columbia.edu, Linux ARM 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 11, 2022 at 10:52 AM Raghavendra Rao Ananta wrote: > > On Mon, Jan 10, 2022 at 3:57 PM Jim Mattson wrote: > > > > On Mon, Jan 10, 2022 at 3:07 PM Raghavendra Rao Ananta > > wrote: > > > > > > On Fri, Jan 7, 2022 at 4:05 PM Jim Mattson wrote: > > > > > > > > On Fri, Jan 7, 2022 at 3:43 PM Raghavendra Rao Ananta > > > > wrote: > > > > > > > > > > Hi Reiji, > > > > > > > > > > On Thu, Jan 6, 2022 at 10:07 PM Reiji Watanabe wrote: > > > > > > > > > > > > Hi Raghu, > > > > > > > > > > > > On Tue, Jan 4, 2022 at 11:49 AM Raghavendra Rao Ananta > > > > > > wrote: > > > > > > > > > > > > > > Capture the start of the KVM VM, which is basically the > > > > > > > start of any vCPU run. This state of the VM is helpful > > > > > > > in the upcoming patches to prevent user-space from > > > > > > > configuring certain VM features after the VM has started > > > > > > > running. > > > > > > > > What about live migration, where the VM has already technically been > > > > started before the first call to KVM_RUN? > > > > > > My understanding is that a new 'struct kvm' is created on the target > > > machine and this flag should be reset, which would allow the VMM to > > > restore the firmware registers. However, we would be running KVM_RUN > > > for the first time on the target machine, thus setting the flag. > > > So, you are right; It's more of a resume operation from the guest's > > > point of view. I guess the name of the variable is what's confusing > > > here. > > > > I was actually thinking that live migration gives userspace an easy > > way to circumvent your restriction. You said, "This state of the VM is > > helpful in the upcoming patches to prevent user-space from configuring > > certain VM features after the VM has started running." However, if you > > don't ensure that these VM features are configured the same way on the > > target machine as they were on the source machine, you have not > > actually accomplished your stated goal. > > > Isn't that up to the VMM to save/restore and validate the registers > across migrations? Yes, just as it is up to userspace not to make bad configuration changes after the first VMRUN. > Perhaps I have to re-word my intentions for the patch- userspace > should be able to configure the registers before issuing the first > KVM_RUN. Perhaps it would help if you explained *why* you are doing this. It sounds like you are either trying to protect against a malicious userspace, or you are trying to keep userspace from doing something stupid. In general, kvm only enforces constraints that are necessary to protect the host. If that's what you're doing, I don't understand why live migration doesn't provide an end-run around your protections. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm