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=-5.3 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,USER_AGENT_SANE_1 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 85475C433DB for ; Tue, 16 Feb 2021 16:58:54 +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 142CE64DCF for ; Tue, 16 Feb 2021 16:58:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 142CE64DCF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk 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:References:Message-ID: Subject: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=PYF6pJPXQHpFbGSvQrHuOCry71I9e+nzNaxFE4J2ixQ=; b=ObtWwqww566aZKE6l/iDWV/uX q3ZQLBwsyGvCpXf3O7G+F2KA4IP1wr/rTKger3ppgymvj2VPvXtH6W9MnMKZmS4W0kWEEmiSzJXlq r/ySi06DUfUwbcliGUaa0dH9LZwuGksqo9F27m1H52+myygPCzMZEAbd3TuIA/TomiqDew98iTci9 E1URcjWNerEOMwZfq0NTewQgl0xxTPky4l6mBCkUFO3+6lte2DbHEWeA+LlCBnJPkvINAg6lkGFe7 UrTmgePkT9OUTxpNBs6pRFwbffYM5G4sHnJBskKmVvI/OcD6Ougj4NS9EYg8GWmUHOJ8Adq9b8HG1 c/pgKux7w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lC3ez-0006Do-7K; Tue, 16 Feb 2021 16:57:13 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1lC3ex-0006DQ-Bb for linux-arm-kernel@lists.infradead.org; Tue, 16 Feb 2021 16:57:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FgKVOLXI7zARf5EV1G9OGsEtIxVsmPlx5HyqDPfvlgY=; b=dmhnomhfXkumwxOHcSy/t1gFx A4sS0JOpeMDjlF5heJOz73CalWQ96liVEUC3b+XEnpZPcJ6zx1QU4YbnxmWX3UyXSK4jHcRxyJQ7x GCi4mKaA1e/8UDLlF04j1LzAJSm+X1VCXzk9j56q+DQJXD0GlT7C3BBvYQkWG4VXR7kRRcmIeL3El IAg9gka5+MJEiFOwxRT1NRPTO1mg0lHOXfDOIRZbc3TwFcDZd6TkZs9GV8vHnPbYiqBEmI8ebw4Z3 hklT0XNObdXHGZmiQhckHLlIWvH/kd7s0R0fg3lwDCjWB9rPNIRHw4HQ/yi7FVkVHk7Zmdb63sz6Y uSI6G4Yew==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:44252) by pandora.armlinux.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lC3es-00020S-HJ; Tue, 16 Feb 2021 16:57:06 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1lC3er-0002uB-Bb; Tue, 16 Feb 2021 16:57:05 +0000 Date: Tue, 16 Feb 2021 16:57:05 +0000 From: Russell King - ARM Linux admin To: Souvik Chakravarty Subject: Re: [PATCH v6] Add virtio SCMI device specification Message-ID: <20210216165705.GB1463@shell.armlinux.org.uk> References: <20210212095920.249768-1-peter.hilber@opensynergy.com> <20210216161208.GA1463@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210216_115711_424124_7D9FE20E X-CRM114-Status: GOOD ( 21.72 ) 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" , Sudeep Holla , Peter Hilber , Cristian Marussi , "virtio-comment@lists.oasis-open.org" , "alex.bennee@linaro.org" , "linux-arm-kernel@lists.infradead.org" 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, 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. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel