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 AAF7BC433F5 for ; Wed, 19 Jan 2022 00:07:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 0C62649DF6; Tue, 18 Jan 2022 19:07:54 -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 HH-20DLtaT88; Tue, 18 Jan 2022 19:07:52 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id C418C49E2A; Tue, 18 Jan 2022 19:07:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id A763849E1A for ; Tue, 18 Jan 2022 19:07:51 -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 Za-RZ9bgvJfN for ; Tue, 18 Jan 2022 19:07:50 -0500 (EST) Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 9D08E49DF6 for ; Tue, 18 Jan 2022 19:07:50 -0500 (EST) Received: by mail-pf1-f182.google.com with SMTP id r5so866411pfl.2 for ; Tue, 18 Jan 2022 16:07:50 -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=fWaNHtaKFDNOV6FIXJ+FLSmch3KMJPUbCpfAKQyCCRftaWDMJe3c+RTyM9gqZIxzv7 c2xloPNZK/eMKXq3mg1SiXOS/M9deEgLvscOtZV+DinZlRd0LwNqqKk7Z7ip+rxcPyDR L9AA1seRtke9gBjrHh4vJPLDgNn1Ht041rYA5FSgmB6dsCl6NybVcnM1/4j/MRagpqx3 +G/qDRuW08ikeQTpIN15saFayN7Dmbquqh0JOHYkmcIFhONG8vGDNre5+Zojmnj62exw G4L5vKKMIHYdYMXnJ+zQZ0bGajJL770MVjpTDg0vlNlZTV+VY+6uOcU8BfDIF3p0lOkh Jd+g== X-Gm-Message-State: AOAM530AnAfSD6StLAB+fMvDZz3WQZ8aJnHQNb63HYeht0kXrski9LUE tD+7r6pE9P29NnzT7RFrWC2RLw== 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 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 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. _______________________________________________ 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 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 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 75604C433F5 for ; Wed, 19 Jan 2022 00:07:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343585AbiASAHu (ORCPT ); Tue, 18 Jan 2022 19:07:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48436 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234642AbiASAHu (ORCPT ); Tue, 18 Jan 2022 19:07:50 -0500 Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0A303C06161C for ; Tue, 18 Jan 2022 16:07:50 -0800 (PST) Received: by mail-pf1-x434.google.com with SMTP id q25so844127pfl.8 for ; Tue, 18 Jan 2022 16:07:50 -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=8PyBOr/T6SFbEHk14CodSk5KssK1SMA/SAhW/1yXg0Dq8kE2a3fmExoxVrYzztb9Gf Qy3gR0jRja2L6Av9/H7WOual/Cuz/2npnIupqgeQd5qo5hSv9k/CrQ1a1ZKAjyhQTskB lzCWoV076+fzax6NV/14tSLFmegQI0UZrJRCkcbnEYFeVtdExX8h5gD7vl/U1B05tCgL mQNDUTyFuSUftAIHlSR7Ms/m8N55WbG0Z06N5jaHFDFJ1vkjFYZalEftM89ZTrcp6kj3 USRMMTQeC7R7rE9hAQgMZ2yS09jJtczZMRBypEdZR0nf2CEiUeLpgMp/d6BnLIVxt5IZ vk0A== X-Gm-Message-State: AOAM532shzUwj5CywpHsCJPhDA+aE+My44+leeex2uUvKCGkfn/h5zZK 1Vv9/lWrMxL/V/63wTYa5pEeqQ== 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: kvm@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.