OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [PATCH v6] Add virtio SCMI device specification

On 16.02.21 18:31, Souvik Chakravarty wrote:
>> From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
>> 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 <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.
> [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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]