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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Mon, Jul 03, 2017 at 03:53:42PM +0100, 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:
> > > ...
> > > > > 
> > > > > 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.
> > 
> > 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.

I think this is a grey area that we should try to avoid as much as
possible. What constitutes a XSA should be clearly defined, so that
there's no room for speculation or subjective decisions.

Following from the example above (and I'm really not doubting Andrew's
objective criteria here) but what might not seem as a relevant issue
to Andrew (or the security team) in general might be severe to other
parties IMHO, and since not everyone has a stake into what
constitutes a XSA the process would become unfair to them.

Roger.

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