On 16.02.21 18:31, Souvik Chakravarty wrote: >> From: Russell King - ARM Linux admin <[email protected]> >> 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 <[email protected]> >>>> 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
