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 82009C433F5 for ; Wed, 19 Jan 2022 00:09:25 +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=FH4tTd3b7Lmajzh9M6+E4ZZmCy+MiaM/shheCDh0+5U=; b=2z3nGM56yE4rnQ fVrG5QH1N6QokktLpK4oHvCIUDkHbiPZzWJ1dt43xgjyWMyzP+gzczomYabHBYxplPuWtEdytOqWT zGR9mElB72yDgVz+mLLEv6cOMa83qhWluhiEK5kh0h492SQznynb1gYkRzURXSueyl7LR6GRdwzGf yFc1ivdUShFFvKEMeHvT4hfJeoxgjHIuQlZd7HL8FtWvlbRhIcvgvZrNeZ60Mc8LY5E9oQ564Bg7/ TAknlbEPGCnXQXOl/nD+VRsFRFkc3GsFaoexqRSYmwVZp+akQ9TUQsX/oyYbQ+C6Tevo3aDVcMbVg aihl/iuZWBbzn6PEqP4w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n9yW7-003JQv-Bp; Wed, 19 Jan 2022 00:07:59 +0000 Received: from mail-pf1-x42c.google.com ([2607:f8b0:4864:20::42c]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n9yW4-003JPB-DN for linux-arm-kernel@lists.infradead.org; Wed, 19 Jan 2022 00:07:57 +0000 Received: by mail-pf1-x42c.google.com with SMTP id 128so826423pfe.12 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=iZdYjA2vpmhZez/K+t7lYL5qDTdXMa3oDxKxlJ/89ccb3ZhnEEyKvRKDSY3Vxx29jK BX590fsV1PT2uPltOU66+ODUc2TEV/POogXaum4emJtzjUer0e2z8uRAPCkgcdR/qrNp rFYQwgqbqJAJ6K2NNeP7+YQBK3fOcYPbQDKQekzwHd6XE+32Zcejzl04f1VweTwrojdH p5AyOzLPnJNJ9oytv2yGmtnASFHZA7LokUyMaliCo6BU31R3Bhh2PW6bosZvdfZh+6H9 ofmZSyLLNX8kt9/M21nDcIgWxwxJlIg1YIgL9jZmv06wqHxN9gCwgGdIiUqvW3tbRCaj 44/w== X-Gm-Message-State: AOAM5327GvTD1wNYVyGOCXD76twJ1Si3ITn+HinCy9yBuSI0nPC5utX/ cCUA4LE9EAFBYSR2X3HDtsbE7Q== 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-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220118_160756_483646_D322F7A5 X-CRM114-Status: GOOD ( 14.86 ) 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 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel