Re: [Xen-devel] [PATCH v5 1/4] livepatch/docs: Document .bss not being cleared, and .data potentially having changed values

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.09.16 at 17:59, <konrad.wilk@xxxxxxxxxx> wrote:
> On Mon, Sep 12, 2016 at 01:49:51AM -0600, Jan Beulich wrote:
>> >>> On 11.09.16 at 17:48, <konrad.wilk@xxxxxxxxxx> wrote:
>> > --- a/docs/misc/livepatch.markdown
>> > +++ b/docs/misc/livepatch.markdown
>> > @@ -875,6 +875,12 @@ section and the new function will reference the new 
>> > string in the new
>> >  
>> >  This is implemented in the Xen Project hypervisor.
>> >  
>> > +Note that the .bss section is only cleared when the ELF payload is 
>> > uploaded.
>> > +Subsequent apply/revert/apply operation do no clear the .bss (or reset the
>> > +.data to what it was when loaded). Hence it is the responsibility of the
>> > +creator of the payload to reset these values to known good state if they
>> > +depend on them having certain values at apply/revert states.
>> 
>> Was it, as an alternative, considered to disallow re-applying a
>> reverted patch without re-uploading?
> 
> I was thinking about it but not exactly sure of the ramifications.
> 
> That is if you go this route - revert a patch - we could go the
> next step and just unload it. But that puts some question on how
> to schedule that without corruption - say we have payload A,B and we
> are replacing A,B with C. A,B should be reverted and unloaded..
> 
> That means some form of list .. Ugh.
> 
> We could do a simpler way (which is what I think inline with your
> suggestion). This does the trick (and needs to be split up obviously)
> and also handles the case where you only have .text changes (like
> for NOPs).

At least that draft patch looks reasonable at a first glance.

Jan


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