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

[NathanStuder <nathan.studer@xxxxxxxxxxxxxxx>]

On 11/02/2017 01:34 PM, George Dunlap wrote:
> On 10/27/2017 04:09 PM, NathanStuder wrote:
>>
>>
>> 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?
> 
> In our past discussions I don't think anyone has thought the "everything
> has to be tested in osstest" strategy is really feasible.  So I think we
> were going for a model where it just had to be regularly tested
> *somewhere*, more or less as a marker for "is this functionality
> important enough to people to give security support".
> 
>>> 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.
> 
> OK -- in that case, if it's OK with you, I'll list ArinC as 'Supported'.

We're good with that.  Thanks.

     Nate

> 
> Thanks,
>  -George
> 

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