Re: [Xen-devel] [PATCH RFC v2] Add SUPPORT.md

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

> On 27 Sep 2017, at 13:57, Robert VanVossen <robert.vanvossen@xxxxxxxxxxxxxxx> 
> wrote:
> 
> 
> 
> On 9/26/2017 3:12 AM, Dario Faggioli wrote:
>> [Cc-list modified by removing someone and adding someone else]
>> 
>> On Mon, 2017-09-25 at 16:10 -0700, Stefano Stabellini wrote:
>>> On Mon, 11 Sep 2017, George Dunlap wrote:
>>>> +### RTDS based Scheduler
>>>> +
>>>> +    Status: Experimental
>>>> +
>>>> +A soft real-time CPU scheduler built to provide guaranteed CPU
>>>> capacity to guest VMs on SMP hosts
>>>> +
>>>> +### ARINC653 Scheduler
>>>> +
>>>> +    Status: Supported, Not security supported
>>>> +
>>>> +A periodically repeating fixed timeslice scheduler. Multicore
>>>> support is not yet implemented.
>>>> +
>>>> +### Null Scheduler
>>>> +
>>>> +    Status: Experimental
>>>> +
>>>> +A very simple, very static scheduling policy 
>>>> +that always schedules the same vCPU(s) on the same pCPU(s). 
>>>> +It is designed for maximum determinism and minimum overhead
>>>> +on embedded platforms.

...

>> Actually, the best candidate for gaining security support, is IMO
>> ARINC. Code is also rather simple and "stable" (hasn't changed in the
>> last... years!) and it's used by DornerWorks' people for some of their
>> projects (I think?). It's also not tested in OSSTest, though, and
>> considering how special purpose it is, I think we're not totally
>> comfortable marking it as Sec-Supported, without feedback from the
>> maintainers.
>> 
>> George, Josh, Robert?
>> 
> 
> Yes, we do still use the ARINC653 scheduler. Since it is so simple, it hasn't
> really needed any modifications in the last couple years.
> 
> We are not really sure what kind of feedback you are looking from us in 
> regards
> to marking it sec-supported, but would be happy to try and answer any 
> questions.
> If you have any specific questions or requests, we can discuss it internally 
> and
> get back to you.

I think there are two sets of issues: one around testing, which Dario outlined.

For example, if you had some test harnesses that could be run on Xen release 
candidates, which verify that the scheduler works as expected, that would
help. It would imply a commitment to run the tests on release candidates.

The second question is what happens if someone reported a security issue on
the scheduler. The security team would not have the capability to fix issues in 
the ARINC scheduler: so it would be necessary to pull in an expert under 
embargo to help triage the issue, fix the issue and prove that the fix works. 
This 
would most likely require "the expert" to work to the timeline of the security
team (which may require prioritising it over other work), as once a security 
issue 
has been reported, the reporter may insist on a disclosure schedule. If we 
didn't 
have a fix in time, because we don't get expert bandwidth, we could be forced 
to 
disclose an XSA without a fix.

Does this make sense?

Lars



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