[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Notes on stubdoms and latency on ARM



On 20/06/17 11:00, Dario Faggioli wrote:
> On Mon, 2017-06-19 at 11:26 -0700, Volodymyr Babchuk wrote:
>> On 19 June 2017 at 02:37, George Dunlap <george.dunlap@xxxxxxxxxx>
>> wrote:
>>> If you want this "EL0 app" thing to be able to provide extra
>>> security
>>> over just running the code inside of Xen, then the code must not be
>>> able
>>> to DoS the host by spinning forever instead of returning.
>>
>> Right. This is a problem. Fortunately, it is running with interrupts
>> enabled, so next timer tick will switch back to XEN. There you can
>> terminate app which is running too long.
>>
> What timer tick? Xen does not have one. A scheduler may setup one, if
> it's necessary for its own purposes, but that's entirely optional. For
> example, Credit does have one; Credit2, RTDS and null do not.
> 
> Basically, (one of the) main purposes of this new "EL0 app mechanism"
> is playing behind the scheduler back. Well, fine, but then you're not
> allowed to assume that the scheduler will rescue you if something goes
> wrong.

Well another possibility would be to add "timeouts" to "calls" into the
el0 app: i.e., part of the calling mechanism itself would be to set a
timer to come back into Xen and fail the call.

But what to do if you fail?  You could just stop executing the "app",
but there's no telling what state its memory will be in, nor any device
it's using.  It's probably not safe to continue using.  Do you crash it?
 Restart it?

 -George

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.