[Xen-devel] Livepatch for Xen 4.9

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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).
 b) Restart the shrinking of code using__LINE__
 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
 e) ? 

 g) Make XENPF_get_symbol also include Live Patch symbols.


I was wondering if folks could put in their preference and what they are 
thinking
to work on during 4.9?


During 4.8 I took a stab at a) and c).

The 'a)' is a thorny one as:
 1) If we get an NMI during patching we better not be patching MCE/NMI code! 
This could be avoided
    by annotating all the MCE/NMI code and have a 'blacklist' of functions that 
MUST NEVER BE PATCHED.
    But that may be difficult as that code can reach in many parts (especially 
MCE which wants to
    send an event channel, hence touches normal event channel code).

 2) We could also do some form of restartable patching. That is seed the code 
(where we are going to
    put a trampoline) with 'CC'. Then do memcpy over the the 'CC' the new 
instructions (jump). If the
    NMI/MCE handler hits that code it would call the int3 - which we expand now 
to take over and check
    whether the EIP is in the location which we just seeded with 'CC' - and if 
so it can memcpy the
    trampoline code in (with a slight twist - we first memcpy the displacement, 
so the start of a function
    would be say: CC 00 23 00 10 - and then we do a single write to replace 
'CC' with 'E9').
   
    We could also (to combat bitrotting) change this a bit more - the debugger 
handler is in charge of
    actually memcpying and the arch_livepatch_apply just calls 'int 3' (after 
it has seeded the area with 'CC').

    Either of this would would require some global livepatch->debugger handler 
handover structure with
    the EIP to patch over and the insns.


The 'c)' needs a bit more work.


Also I was thinking we can drop the IRC meeting we have setup. It has been 
quite useful during the
starting stage to re-sync patches but at this point I think emails are more 
suited?


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