Re: Livepatch for Xen 4.9

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 03/10/16 15:16, Konrad Rzeszutek Wilk wrote:
> Hey!
>
> [CC-ing xen-devel]
>
> Xen 4.8-rc1 is out and means taking a break from some of the Livepatch hypervisor
> parts for me.
>
> My plan for 4.8 is to concentrate on any livepatch fallout and doing OSSTest along
> with Marcos (CC-ed) and see if we can wrestle it to expand on what
> we want to have done.
>
> However going forward (Xen 4.9) I believe the top issues we need
> to get addressed are:
>
>  a) "A better mechanism to "mask" NMIs during patching. The existing mechanism looses
>    NMI if they have been sent and we don't have a mechanism to replay them. Note that
>    this is also fixes alternative section patching. Could (like Linux) annotate handlers don't get patched."
>    (https://wiki.xenproject.org/wiki/LivePatch).

You cant mask NMIs, and as we have alternatives at the head of the
entrypoints, we need to work towards making patching safe on these
paths.  The traditional way is with 0xcc and magic in the debug trap
handler to take over the responsibility of patching.

>  b) Restart the shrinking of code using__LINE__

+1 (shame these patches missed 4.8)

>  c) When figuring out the new_addr, take into account name being <symbol>+<offset>.
>  d) Make asm code be in its own section. That eases the livepatch tools work in figuring out a change.
>     See https://lkml.org/lkml/2009/2/24/364

d.1) Reducing the quantity of ASM code outright.

As a start, {,compat_}create_bounce_frame() should definitely be written
in C, and would half the quantity of runtime ASM we have.  (Worse, we
already have C versions of create_bounce_frame() with
ever-so-slighty-different semantics).  I also have my eye on the general
exception handling path, which I think can safely move up into C.

~Andrew

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