linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Souvik Chakravarty <Souvik.Chakravarty@arm.com>
Cc: "virtio-dev@lists.oasis-open.org"
	<virtio-dev@lists.oasis-open.org>,
	"jean-philippe@linaro.org" <jean-philippe@linaro.org>,
	Sudeep Holla <Sudeep.Holla@arm.com>,
	Peter Hilber <peter.hilber@opensynergy.com>,
	Cristian Marussi <Cristian.Marussi@arm.com>,
	"virtio-comment@lists.oasis-open.org"
	<virtio-comment@lists.oasis-open.org>,
	"alex.bennee@linaro.org" <alex.bennee@linaro.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v6] Add virtio SCMI device specification
Date: Tue, 16 Feb 2021 16:57:05 +0000	[thread overview]
Message-ID: <20210216165705.GB1463@shell.armlinux.org.uk> (raw)
In-Reply-To: <DBBPR08MB4790802EA436661E4AEEEFF682879@DBBPR08MB4790.eurprd08.prod.outlook.com>

On Tue, Feb 16, 2021 at 04:48:30PM +0000, Souvik Chakravarty wrote:
> > From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> > 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

  reply	other threads:[~2021-02-16 16:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-12  9:59 [PATCH v6] Add virtio SCMI device specification Peter Hilber
2021-02-15 13:20 ` Cristian Marussi
2021-02-16 15:11   ` Peter Hilber
2021-02-16 16:23     ` Cristian Marussi
2021-02-16 16:12 ` Russell King - ARM Linux admin
2021-02-16 16:48   ` Souvik Chakravarty
2021-02-16 16:57     ` Russell King - ARM Linux admin [this message]
2021-02-16 17:31       ` Souvik Chakravarty
2021-02-16 19:26         ` Peter Hilber
2021-03-11 17:19 ` Peter Hilber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210216165705.GB1463@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=Cristian.Marussi@arm.com \
    --cc=Souvik.Chakravarty@arm.com \
    --cc=Sudeep.Holla@arm.com \
    --cc=alex.bennee@linaro.org \
    --cc=jean-philippe@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=peter.hilber@opensynergy.com \
    --cc=virtio-comment@lists.oasis-open.org \
    --cc=virtio-dev@lists.oasis-open.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).