Re: [ARM] Native application design and discussion (I hope)

[George Dunlap <george.dunlap@citrix.com>]

On 09/05/17 19:29, Stefano Stabellini wrote:
> On Tue, 9 May 2017, Dario Faggioli wrote:
>>>> And it should not be hard to give such code access to the context
>>>> of
>>>> the vCPU that was previously running (in x86, given we implement
>>>> what
>>>> we call lazy context switch, it's most likely still loaded in the
>>>> pCPU!).
>>>
>>> I agree with Stefano, switching to the idle vCPU is a pretty bad
>>> idea.
>>>
>>> the idle vCPU is a fake vCPU on ARM to stick with the common code
>>> (we 
>>> never leave the hypervisor). In the case of the EL0 app, we want to 
>>> change exception level to run the code with lower privilege.
>>>
>>> Also IHMO, it should only be used when there are nothing to run and
>>> not 
>>> re-purposed for running EL0 app.
>>>
>> It's already purposed for running when there is nothing to do _or_ when
>> there are tasklets.
>>
>> I do see your point about privilege level, though. And I agree with
>> George that it looks very similar to when, in the x86 world, we tried
>> to put the infra together for switching to Ring3 to run some pieces of
>> Xen code.
> 
> Right, and just to add to it, context switching to the idle vcpu has a
> cost, but it doesn't give us any security benefits whatsever. If Xen is
> going to spend time on context switching, it is better to do it in a
> way that introduces a security boundary.

"Context switching" to the idle vcpu doesn't actually save or change any
registers, nor does it flush the TLB.  It's more or less just accounting
for the scheduler.  So it has a cost (going through the scheduler) but
not a very large one.

But the context here is that Andrii asked something about whether this
"EL0 App" functionality could be used to service Xen as well as a
domain.  You said it didn't make sense, and Dario (as I understand it)
was pointing out that we already did something similar with tasklets.
If there was a need to be able to "upload" user-specified routines that
would handle events generated by the hypervisor rather than events
generated by a guest, that would indeed be a possibility.  It would
essentially be the equivalent of a deprivileged, untrusted tasklet.

At the moment I can't foresee the need for such a mechanism, and I don't
particularly think that we should keep that use case in mind when
designing the "App" interface.  But it is an interesting idea to keep in
our back pockets in case a use case comes up later.

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel