Re: [Xen-devel] [PATCH for-4.9] livepatch: Declare live patching as a supported feature

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 08/03/2017 06:20 PM, George Dunlap wrote:
> On 07/03/2017 03:53 PM, Ross Lagerwall wrote:
>> On 06/30/2017 02:42 PM, George Dunlap wrote:
>>> On 06/28/2017 05:18 PM, Ross Lagerwall wrote:
>>>> On 06/27/2017 10:17 AM, George Dunlap wrote:
>>>>> On 26/06/17 18:30, Andrew Cooper wrote:
>>>>>> On 26/06/17 18:00, George Dunlap wrote:
>>>>>>> On 26/06/17 16:36, Ross Lagerwall wrote:
>>>> ...
>>>>> You seem to be simply refusing to use your imagination.  Step back.
>>>>> Imagine yourself in one year.  You come to the office and find an
>>>>> e-mail
>>>>> on security@ which says, "Livepatch tools open a security hole when
>>>>> compiling with gcc x.yy".  You realize that XenVerson ${LATEST-2} uses
>>>>> gcc x.yy, so you take a closer look at that livepatch, only to discover
>>>>> that the livepatches generated actually do contain the bug, but you
>>>>> missed it because ${LATEST-[0,1]} were perfectly fine (since they used
>>>>> newer versions of gcc), the difference was subtle, and it passed all
>>>>> the
>>>>> functional tests.
>>>>>
>>>>> Now all of the customers that have applied those patches are
>>>>> vulnerable.
>>>>>
>>>>> Do you:
>>>>>
>>>>> 1. Tell the reporter to post it publicly to xen-devel immediately,
>>>>> since
>>>>> livepatch tools are not security supported -- thus "zero-day"-ing all
>>>>> your customers (as well as anyone else who happens to have used x.yy to
>>>>> build a hypervisor)?
>>>>>
>>>>> 2. Secretly take advantage of Citrix' privileged position on the
>>>>> security list, and try to get an update out to your customers before it
>>>>> gets announced (but allowing everyone *else* using gcc x.yy to
>>>>> experience a zero-day)?
>>>>>
>>>>> 3. Issue an XSA so that everyone has the opportunity to fix things up
>>>>> before making a public announcement, and so that anyone not on the
>>>>> embargo list gets an alert, so they know to either update their own
>>>>> livepatches, or look for updates from their software provider?
>>>>>
>>>>> I think #3 is the only possible choice.
>>>>>
>>>>>    -George
>>>>>
>>>>
>>>> The issue here is that any bug in livepatch-build-tools which still
>>>> results in output being generated would be a security issue, because
>>>> someone might have used it to patch a security issue.
>>>> livepatch-build-tools is certainly not stable enough yet (ever?) to be
>>>> treated in this fashion.
>>>
>>> You didn't answer my question.  If the situation described happens, what
>>> position do you want Andrew to be put in?  (If I missed a potential
>>> action, let me know.)
>>>
>>
>> I would choose #3 as it is the obvious choice. But I still don't think
>> it is a sensible idea to have security support for the build tools, at
>> least at this point. The same scenario could be posed for a nasty bug
>> that affects Xen 4.4 only, but it is now just out of security support.
>> IMO something being not supported doesn't preclude it from having an XSA
>> released if there is a particularly nasty vulnerability found.
> 
> Well basically I think we agree, but we're using different terms.  You
> want to say, "This isn't security supported, but if important bug is
> actually found then we'll issue an XSA".  I want to say, "This is
> security supported, because if an important bug is actually found we'll
> issue an XSA."
> 
> So it seems to me there are likely two things that make you resistant to
> calling it "security supported":
> 
> 1. The fear that we'll be issuing XSAs over trivial things that don't matter
> 
> 2. The fear that people will not do due diligence when creating patches
> with the tools.
> 
> I think #1 is just a misconception.  *Every* bug reported to us about
> any part of the code we go through the process of trying to determine
> its impact and whether we need to issue an XSA or not.  All of the
> examples put forward of things we don't want to issue an XSA for are
> things that I'm sure we would not issue an XSA for.
> 
> For #2, that is a reasonable fear, but we can deal with that in a
> different way than calling the tools "unsupported".  We can, for
> instance, mention that in the documents.  We can add a warning message
> that the build tools output saying that the result should be manually
> inspected for correctness.

We need to get a resolution on this.  Anyone else (particarly
committers) want to give their opinion?

 -George

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