[PATCH v6] Add virtio SCMI device specification

[Peter Hilber]

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