[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH for-4.9] livepatch: Declare live patching as a supported feature
- To: George Dunlap <george.dunlap@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxx>
- From: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>
- Date: Mon, 3 Jul 2017 15:53:42 +0100
- Cc: Lars Kurth <lars.kurth@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <liuw@xxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>
- Delivery-date: Mon, 03 Jul 2017 14:54:25 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
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.
--
Ross Lagerwall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
