[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
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. -GeorgeThe 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |