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

[Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>]

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:
...
> > We absolutely cannot be in the position of issuing XSAs for situations
> > like this, because there are too many ways where it definitely will go
> > wrong, and we'd end up issuing XSAs saying "remember to clean your
> > working tree before building a livepatch".  This is of course absurd.
> Your argument is that because we do not issue XSAs for *user mistakes*,
> that therefore we should not issue XSAs for *bugs in the tool*.
>
> That is of course absurd.  We do not issue XSAs for user mistakes in
> building the hypervisor either (for instance, switching gcc versions
> without cleaning the hypervisor tree), and yet we still issue XSAs for
> bugs in the hypervisor itself.
>
> > IMO, The only viable option is to exclude livepatch-build-tools entirely
> > from security scope.  It is already the case that people producing
> > livepatches need to check the resulting livepatch binary for sanity, and
> > test it suitably in a development environment before use in production.
> Look, it sounds like right now you are going through all the livepatches
> with a fine-tooth comb *because* the tools are (or recently have been)
> unreliable.  But at some point in the future, the patch generation
> mechanism will become more reliable.  After 20 XSAs over six months in
> which the livepatch tool created the correct patch, you will become more
> complacent.  You won't look as closely; it's human nature.
>
> 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.
--
Ross Lagerwall

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