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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

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

Thanks,
 -George

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