Re: [Xen-devel] Is:livepatch-build-tools.git declare it supported? Was:Re: [PATCH for-4.9] livepatch: Declare live patching as a supported feature

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> George Dunlap <george.dunlap@xxxxxxxxxx> 08/07/17 12:27 PM >>>
>So it seems that people are still not quite clear about what I'm proposing.

And indeed your examples helped me understand better what you mean
(or at least I hope they did).

>Suppose someone builds a livepatch with the correct compiler, with a
>correct patch (that would fix the bug if rebooted into a new
>hypervisor), with correct fix-up code.  Suppose that the bug passes all
>reasonable testing; but that, *due to a bug in the tools*, the patch
>also gives PV guests access to hypervisor memory.  Is this a security
>issue?  Yes -- the human told it to do safe thing X ("build a livepatch
>based on correct inputs to fix this bug") and it did unsafe thing Y
>("build a livepatch that opens up a new security hole").

There's one more factor here: The livepatch tools may behave properly
with one version of the compiler, and improperly with another. Or they
may behave properly with the Oracle patched hypervisor sources, but
improperly with the Citrix ones (assuming every distro carries a different
set of patches on top of an upstream stable release or branch).

>We could even place more restrictions on the scope if we wanted to.  We
>could say that we only support the livepatch tools generating patches
>for XSAs.

For me, much depends on how tight such restrictions would be. I.e.
with the examples given above, how would we determine a canonical
livepatch-tools / hypervisor pair (or set of pairs)? After all tools
mis-behavior may be a result of some custom patch in someone's
derived tree.

>> This is very similar to what XSA-155 was - the GCC compiler optimizations
>> added a nice jump table that was accessed twice. And the offset was
>> retrieved from the shared ring.
>>
>> But we didn't do an XSA-155 for the GCC compiler. That is we didn't
>> file a ticket with GCC saying 'Hey, your compiler can create an race
>> on shared memory. Could you make your compiler be smarter in these cases'
>> We instead wrote code with this optimization in mind with more
>> barriers.
>
>Right -- so the gcc compiler guys are using a specification that allows
>that behavior.  So from their perspective, we told the compiler to do
>unsafe thing Y (or at least, said that we were OK with it doing unsafe
>thing Y), and it did unsafe thing Y -- a security issue for Xen, but not
>for gcc.  If gcc had *violated* the spec when causing the security
>issue, then we certainly would have called that a security issue in gcc.

But would we have issued an XSA? Wouldn't that rather be a CVE
against gcc then?

Jan


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