[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]