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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 39B1DC433E0 for ; Tue, 16 Feb 2021 19:29:10 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E1FFE64ED6 for ; Tue, 16 Feb 2021 19:29:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E1FFE64ED6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=opensynergy.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=R0ES6l6Bkvi3W73QiJL84JRcmMHE8fFrR93KVu5v8Gg=; b=WlV9BZilAYT8wmiLGoXRd6d/P aw9GcjWR+7bqdAuppnUmz50cFl7xnxmhZpqV5Abp7q66/kToplvRb8szur/W4v6+3gyBzITb/qUWA 0ySpQb4+2qttPIKg2tJHxFSFiPYHpKG4qQbOXi7Ee9Bojhm4BwCUZAb5LIXKmHP+kWYNJbNfPEweR 8GO/jtD7admxlLKUCcrip/6IOLwi5/Gr2QlzMcbFOR0V/HOETGvADwsn02K+rcFdUAc5fQTJ6Wu9S bjO9+ycpa8Qjz3LxtrrCguk9QLBAf0gN/x9BCBr7zz6abi0CMOcCpkHs4uUQDwUFy/9CGJFbjiKDF bmi99KpIg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lC5zx-000527-1I; Tue, 16 Feb 2021 19:27:01 +0000 Received: from mx1.opensynergy.com ([217.66.60.4]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1lC5zu-00051M-9B for linux-arm-kernel@lists.infradead.org; Tue, 16 Feb 2021 19:26:59 +0000 Received: from SR-MAILGATE-02.opensynergy.com (localhost.localdomain [127.0.0.1]) by mx1.opensynergy.com (Proxmox) with ESMTP id 4AA18A16C9; Tue, 16 Feb 2021 20:26:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opensynergy.com; h=cc:cc:content-transfer-encoding:content-type:content-type :date:from:from:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=srmailgate02; bh=6W5VbZhvCmF6 c5yntLOHFmaguf0pnZyVwftk+F9jwvU=; b=zQe1gxa5Ku3NMrmXVvZcVp5YIl32 qCdd9n/ZrLjRFBbh47Anl30Z6WWBOTqKY2VxyzEu1vmbFdWKt3TtNXfI07XbIgrd gINoAAFcpU8I0fhzvS1uDJ0AAt7CJZ2x1zwI/YbMGzvZGR0oHZHbNzjz449dwTjK 4heGROxdQI/ZJ0R2JChs20ZKEud8jqnbuGyMvoqtBH3/6INNbyZLvTUIvQ6VnQR2 a4d7mTHdZJNZnD/tBRnMg7sbNultO1t5ncF60f62FtUetcPdroz+10mYfNntwEhR /T1Zgvem3ceYC3UryC74unqhwITSUh4xfq2N1svwZEiZtQNcTdcSh3lrlg== Subject: Re: [PATCH v6] Add virtio SCMI device specification To: Souvik Chakravarty , Russell King - ARM Linux admin References: <20210212095920.249768-1-peter.hilber@opensynergy.com> <20210216161208.GA1463@shell.armlinux.org.uk> <20210216165705.GB1463@shell.armlinux.org.uk> From: Peter Hilber Autocrypt: addr=peter.hilber@opensynergy.com; prefer-encrypt=mutual; keydata= mQGNBFuyHTIBDAClsxKaykR7WINWbw2hd8SjAU5Ft7Vx2qOyRR3guringPRMDvc5sAQeDPP4 lgFIZS5Ow3Z+0XMb/MtbJt0vQHg4Zi6WQtEysvctmAN4JG08XrO8Kf1Ly86Z0sJOrYTzd9oA JoNqk7/JufMre4NppAMUcJnB1zIDyhKkkGgM1znDvcW/pVkAIKZQ4Be3A9297tl7YjhVLkph kuw3yL8eyj7fk+3vruuEbMafYytozKCSBn5pM0wabiNUlPK39iQzcZd8VMIkh1BszRouInlc 7hjiWjBjGDQ2eAbMww09ETAP1u38PpDolrO8IlTFb7Yy7OlD4lzr8AV+a2CTJhbKrCJznDQS +GPGwLtOqTP5S5OJ0DCqVHdQyKoZMe1sLaZSPLMLx1WYAGN5R8ftCZSBjilVpwJ3lFsqO5cj t5w1/JfNeVBWa4cENt5Z0B2gTuZ4F8j0QAc506uGxWO0wxH1rWNv2LuInSxj8d1yIUu76MqY p92TS3D4t/myerODX3xGnjkAEQEAAbQ7cGV0ZXIuaGlsYmVyQG9wZW5zeW5lcmd5LmNvbSA8 cGV0ZXIuaGlsYmVyQG9wZW5zeW5lcmd5LmNvbT6JAc4EEwEIADgCGwMFCwkIBwIGFQoJCAsC BBYCAwECHgECF4AWIQTj5TCZN1jYfjl5iwQiPT9iQ46MNwUCXXd8PQAKCRAiPT9iQ46MN1PT C/4mgNGlWB1/vsStNH+TGfJKt3eTi1Oxn6Uo0y4sXzZg+CHXYXnrG2OdLgOa/ZdA+O/o1ofU v/nLKki7XH/cGsOtZ6n3Q5+irkLsUI9tcIlxLCZZlgDPqmJO3lu+8Uf2d96udw/5JLiPyhk/ DLtKEnvIOnn2YU9LK80WuJk7CMK4ii/bIipS6WFV6s67YG8HrzMKEwIzScf/7dC/dN221wh0 f3uUMht0A7eVOfEuC/i0//Y+ytuoPcqyT5YsAdvNk4Ns7dmWTJ8MS2t2m55BHQnYh7UBOIqB BkEWLOxbs2zZnC5b/yjg7FOhVxUmSP4wU1Tp/ye+MoVhiUXwzXps5JmOuKahLbIysIpeRNxf B8ndHEjKRl6YglPtqwJ45AF+BFEcblLe4eHk3Gl43jfoBJ43jFUSkge9K7wddB2FpaXrpfwM KupTSWeavVwnjDb+mXfqr4e7C4CX3VoyBQvoGGPpK/93cVZInu5zV/OAxSayXt6NqZECkMBu mg7W7hbcQey0K1BldGVyIEhpbGJlciA8cGV0ZXIuaGlsYmVyQG9wZW5zeW5lcmd5LmNvbT6J Ac4EEwEIADgWIQTj5TCZN1jYfjl5iwQiPT9iQ46MNwUCXjAOKgIbAwULCQgHAgYVCgkICwIE FgIDAQIeAQIXgAAKCRAiPT9iQ46MN6G+C/0R2UCwDr4XdHCjDETK+nGzwEADTkb/bVvnSP8U 1XpoNuFoG0hpx/L9IOacxKCUwL5wGLQ2YjqfmWl5h5nwL/VmisSjtDBU/E9Te825J6avxyXm aSYehTMlBNgGq6gTgGZ2UywbTx51iPtbtqk5IWQSrJfhHgegyapOvDIe3W/L7WdWhpEUAOS2 Rn1pW//rR1RZW0aCuQSi8eT+HKiFid84Kh9x858oNRc9W1bCGjmkFxyhJdxlF7SdwgFahJDm JHfdRyBcpp31WyofNodzNi/39gnrYbxyQmMSMU6Wi5Y9QIGubBB6BN+JlqL0WKgWfyye/6dp R6BrgRLUHBXFegWWLVvQGDli31kXBT0Aey9GQs2sEG3yoYHRAi9/dOip+rJgzqc+k6exP13g ZNBPc5SCrhWk9B/VrZ+frVBhqbu0hYlAnX39cB4szyOJVkGvXPJ6vsewQBv486kIY7IDC+Rk YtC1zNZKSIWSK1+bIXrIBA45rWb6SGq0CgMYdMvUGd25AY0EW7IdMwEMANZOEgW7gpZr0l4M HVvEZomKRgHmKghiKffCyR/cZdB5CWPEsyD0QMkQCQHg0FUQIB/SyS7hV/MOYL47Zb+QUlBo sMGkyyseEBWx0UgxgdMOh88JxAEHs0gQFYjL13DFLX/JfPyUqEnmWHLmvPpwPy2Qp7M1PPYb /KT8YxQEcJ0agxiSSGC+0c6efziPLW1uvGnQpBXhbLRdmUVS9JE390vQLCjIQWQP34e6MnKr ylqPpOeaiVSC9Nvr44f7LDk0X3Hsg3b4kV9TInGcbskXCB9QnKo6lVgXI9Q419WZtI9T/d8n 5Wx54P+iaw4pISqDHi6v+U9YhHACInqJm8S4WhlRIXhXmDVXBjyPvMkxEYp9EGxT5yeu49fN 5oB1SQCf819obhO7GfP2pUx8H3dy96TvKFEQmuh15iXYCxgltrvy9TjUIHj9SbKiaXW1O45t jlDohZJofA0AZ1gU0X8ZVXwqn3vEmrMLDBiko3gdBy7mx2vl+Z1LJyqYKBBvw+pi7wARAQAB iQG2BBgBCAAgAhsMFiEE4+UwmTdY2H45eYsEIj0/YkOOjDcFAl13fD0ACgkQIj0/YkOOjDfF hwv9F6qVRBlMFPmb3dWIs+QcbdgUW9ViGOHNyjCnr+UBE5jc0ERP3IOzcgqavcL5YpuWadfP n4/LyMDhVcl5SQGIdk5oZlRWQRiSpqS+IIU8idu+Ogl/Hdsp4n9S8GiINNwNh5KzWoCNN0Pp crjuMTacJnZur9/ym9tjr+mMvW7Z0k52lnS9L+CRHLKHpVJSnccpTpShQHa335c5YvRC8NN+ Ygj1uZL/98+1GmP1WMZ6nc1LSFDUxR60cxnlbgH7cwBuy8y5DBeCCYiPHKBglVIp5nUFZdLG /HmufQT3f4/GVoDEo2Q7H0lq3KULX1xEwHFeXHw4NXR7mYeX/eftz/9GFMVU29c72NTw8Uih Oy9qJgNo19wroRYKHLz1eWtMVcqS3hbXm0/QcrG9+C9qCPXVxpC/L0YLAtmdvEIyaFtXWRyW 7UQ3us6klHh4XUvSpsQhOgzLHFJ1LpfcupeBYECJQdxgIYyhgFAwRHeLGIPxjlvUmk22C0ua lbekkuPTQs/m Message-ID: <3feccb6f-1789-4cd8-b18f-748464539a50@opensynergy.com> Date: Tue, 16 Feb 2021 20:26:51 +0100 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-ClientProxiedBy: SR-MAIL-01.open-synergy.com (10.26.10.21) To SR-MAIL-01.open-synergy.com (10.26.10.21) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210216_142658_584086_BD577D54 X-CRM114-Status: GOOD ( 20.61 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "virtio-dev@lists.oasis-open.org" , "jean-philippe@linaro.org" , "virtio-comment@lists.oasis-open.org" , Peter Hilber , "linux-arm-kernel@lists.infradead.org" , Sudeep Holla , "alex.bennee@linaro.org" , Cristian Marussi 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 16.02.21 18:31, Souvik Chakravarty wrote: >> From: Russell King - ARM Linux admin >> Sent: Tuesday, February 16, 2021 4:57 PM >> >> On Tue, Feb 16, 2021 at 04:48:30PM +0000, Souvik Chakravarty wrote: >>>> From: Russell King - ARM Linux admin >>>> Sent: Tuesday, February 16, 2021 4:12 PM I'm not too familiar with >>>> SCMI, but I think this question is worth asking... >>>> >>>> If the SCMI protocol can be used to control system level power >>>> management, and if the intention is to expose this firmware >>>> interface to virtualised guests, what prevents a guest from >>>> controlling the power settings for stuff it should not have access to? >>>> >>>> For example, if it's possible to tell the system to power down a >>>> critical host component through SCMI, what would prevent a guest >>>> requesting that critical component from having its power cut? >>> >>> Short summary: >>> SCMI as a protocol has built in requirements where only the resources >>> (specific clock, sensor etc.) which are specifically needed by a VM >>> are exposed to it. Resources are mapped by Identifiers and if the VM >>> tries to access an identifier which it does not have access to, the >>> SCMI backend can simply ignore or return DENIED. At no point is direct >> access to any power mgmt. hardware granted to any VM, nor is a VM >> supposed to have global access to all system resources. >>> There is always a firmware backend which controls the hardware and >>> services SCMI command requests from agents/guests, after due validation. >>> The SCMI device/firmware which implements the SCMI backend, is >>> responsible for implementing these resource isolation guarantees. >> >> You seem to be saying the SCMI firmware itself is responsible for >> implementing this. Given what I've seen from vendors in ATF, this does not >> leave me with much confidence that there will be sufficient security. It >> concerns me more when you say that the "backend" is responsible for >> making these decisions. This doesn't sound good to me. > > [Somehow realizing I cannot post to virtio-dev...] > Let me try to add a bit of color because I realize I did mix up a few usage models > (baremetal & virtualized) in my previous reply. > > Let me rephrase from the perspective of a virtualized system using Virtio SCMI specifically. > In this specific case, the commands issued by the VM will go to the SCMI virtio backend > which is in the host. This can then choose can choose to reject VM issued SCMI commands. > In my company's implementation, the integrator has to explicitly list every resource which the "firmware" should make available to the virtualization guest. As Souvik wrote, the "firmware" is in fact a dedicated virtualization component, which was designed with security in mind. I hope hearing this lessens your concerns. _______________________________________________ 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: virtio-comment-return-1723-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: References: <20210212095920.249768-1-peter.hilber@opensynergy.com> <20210216161208.GA1463@shell.armlinux.org.uk> <20210216165705.GB1463@shell.armlinux.org.uk> From: Peter Hilber Message-ID: <3feccb6f-1789-4cd8-b18f-748464539a50@opensynergy.com> Date: Tue, 16 Feb 2021 20:26:51 +0100 MIME-Version: 1.0 In-Reply-To: Subject: [virtio-comment] Re: [PATCH v6] Add virtio SCMI device specification Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit To: Souvik Chakravarty , Russell King - ARM Linux admin Cc: "virtio-dev@lists.oasis-open.org" , "jean-philippe@linaro.org" , Sudeep Holla , Peter Hilber , Cristian Marussi , "virtio-comment@lists.oasis-open.org" , "alex.bennee@linaro.org" , "linux-arm-kernel@lists.infradead.org" List-ID: On 16.02.21 18:31, Souvik Chakravarty wrote: >> From: Russell King - ARM Linux admin >> Sent: Tuesday, February 16, 2021 4:57 PM >> >> On Tue, Feb 16, 2021 at 04:48:30PM +0000, Souvik Chakravarty wrote: >>>> From: Russell King - ARM Linux admin >>>> Sent: Tuesday, February 16, 2021 4:12 PM I'm not too familiar with >>>> SCMI, but I think this question is worth asking... >>>> >>>> If the SCMI protocol can be used to control system level power >>>> management, and if the intention is to expose this firmware >>>> interface to virtualised guests, what prevents a guest from >>>> controlling the power settings for stuff it should not have access to? >>>> >>>> For example, if it's possible to tell the system to power down a >>>> critical host component through SCMI, what would prevent a guest >>>> requesting that critical component from having its power cut? >>> >>> Short summary: >>> SCMI as a protocol has built in requirements where only the resources >>> (specific clock, sensor etc.) which are specifically needed by a VM >>> are exposed to it. Resources are mapped by Identifiers and if the VM >>> tries to access an identifier which it does not have access to, the >>> SCMI backend can simply ignore or return DENIED. At no point is direct >> access to any power mgmt. hardware granted to any VM, nor is a VM >> supposed to have global access to all system resources. >>> There is always a firmware backend which controls the hardware and >>> services SCMI command requests from agents/guests, after due validation. >>> The SCMI device/firmware which implements the SCMI backend, is >>> responsible for implementing these resource isolation guarantees. >> >> You seem to be saying the SCMI firmware itself is responsible for >> implementing this. Given what I've seen from vendors in ATF, this does not >> leave me with much confidence that there will be sufficient security. It >> concerns me more when you say that the "backend" is responsible for >> making these decisions. This doesn't sound good to me. > > [Somehow realizing I cannot post to virtio-dev...] > Let me try to add a bit of color because I realize I did mix up a few usage models > (baremetal & virtualized) in my previous reply. > > Let me rephrase from the perspective of a virtualized system using Virtio SCMI specifically. > In this specific case, the commands issued by the VM will go to the SCMI virtio backend > which is in the host. This can then choose can choose to reject VM issued SCMI commands. > In my company's implementation, the integrator has to explicitly list every resource which the "firmware" should make available to the virtualization guest. As Souvik wrote, the "firmware" is in fact a dedicated virtualization component, which was designed with security in mind. I hope hearing this lessens your concerns. This publicly archived list offers a means to provide input to the OASIS Virtual I/O Device (VIRTIO) TC. In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting. Subscribe: virtio-comment-subscribe@lists.oasis-open.org Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org List help: virtio-comment-help@lists.oasis-open.org List archive: https://lists.oasis-open.org/archives/virtio-comment/ Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists Committee: https://www.oasis-open.org/committees/virtio/ Join OASIS: https://www.oasis-open.org/join/