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

[NathanStuder <nathan.studer@xxxxxxxxxxxxxxx>]

On 10/09/2017 10:14 AM, Lars Kurth wrote:
> 
>> 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.

We have an internal Xen test harness that we use to test the scheduler, but I
assume you would like it converted to use OSSTest instead, so that the
tests could be integrated into the main test suite someday?

> 
> 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.

We can support this and have enough staff familiar with the scheduler that
prioritizing security issues shouldn't be a problem.  The maintainers (Robbie
and Josh) can triage issues if and when the time comes, but if you need a more
dedicated "expert" for this type of issue, then that would likely be me.

Sorry for the relatively late response.

     Nate

> 
> Does this make sense?
> 
> Lars
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> https://lists.xen.org/xen-devel
> 

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