Bao support of the SiP Service Call interface

[jdbl24]

Hello,
I have a question regarding how Bao handles the SMC calls related to the SiP service call interface on IMX8QM SoCs.

In Xen, these SMC SiP calls (for dom0) are forwarded to the firmware because many drivers need to issue such SMCs for managing hardware ( xen/arm: Add imx8q{m,x} platform glue ).

I am aware that Bao does not rely on a privileged VM such as Xen, but it looks like Bao does not support the SiP service call interface.

Does this not create limitations for running VMs with Bao on the IMX8QM?
This may also apply to other platforms.

I wonder if the SMC SiP call interface is necessary for the operation of some platforms or if dispensing with it does not create limitations.
If the SMC SiP call interface were necessary for the operation on certain SoCs, how would it be implemented in a hypervisor such as Bao since there is no "Trusted VM"?

Thank you in advance for your reply and have a nice day.

Kind regards,

Jean

[DavidMCerdeira]

Greetings,

I wonder if the SMC SiP call interface is necessary for the operation of some platforms or if dispensing with it does not create limitations.

Bao's current approach is limiting, you are correct.

If the SMC SiP call interface were necessary for the operation on certain SoCs, how would it be implemented in a hypervisor such as Bao since there is no "Trusted VM"?

We are aware we need to tackle support for platform specific features like these. We haven't looked deeply into this subject yet, so I can't say with certainty what is the best approach. From experience, it seems that for some cases validating the SMC SiP call parameters should be sufficient. In other cases access to SMC SiP interface could be used as a way for guest to interfere with each other, and so they cannot be safely supported. At this moment I don't think there's a need for a trusted VM, but again, we haven't looked deeply into this yet.

[josecm]

@jdbl24 Can I ask what specific kind of SiP services you need in your setup?

And as @DavidMCerdeira pointed out, it should be straightforward to pass through these calls for a specific guest, which I believe would in essence become privilege. This is the reason for my previous question. If any of these SiP calls allows the guest to modify platform-wide configurations the guest would become part of the TCB.

[jdbl24]

Thank you @josecm @DavidMCerdeira for your prompt reply.

I do not need specific SiP services; I was just curious about how the SiP interface could be handled in Bao.

In the past, I tried to get Xen running on a Toradex Apalis Board (IMX8QM-based), but I was unable to get a Dom0 running properly since the hypervisor did not forward the SMC SiP calls. When running Xen on both IMX8QM and ZCU104 platforms, I observed that the kernel drivers in Dom0 constantly issue SiP service calls.
Both Jailhouse and Xen simply forward any SMC SIP call issued by the privileged VM (i.e. the Root Cell or Dom0) while rejecting any SMC SiP calls from the other VMs. For this, it is very convenient to rely on a privileged VM (despite the drawbacks regarding the TCB) for managing platform hardware controls while ensuring that an untrusted VM cannot leverage sensitive functions exposed through the SMC SiP interface.

Thus, I was curious how this could be handled in a hypervisor like Bao, which does not rely on a privileged VM. If those SMCs are necessary for some platform specific controls, this inevitably impacts the TCB of the VM running on Bao as well. As @DavidMCerdeira said, the best approach in my opinion would be to implement some access control on the SMC interface but I am not sure it is always sufficient.

[josecm]

As @DavidMCerdeira said, the best approach in my opinion would be to implement some access control on the SMC interface but I am not sure it is always sufficient.

It is our goal to implement these kind of platform-specific checks both for system service hypercalls and other plaform-wide configuration peripherals (e.g., clocks, power, etc). However, it is not in our immediate pipeline...

Why you don't think this might be sufficient?