Re: [PATCH v3 1/9] livepatch: Clear .bss when payload is reverted

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Mon, Aug 15, 2016 at 04:27:38AM -0600, Jan Beulich wrote:
> >>> On 14.08.16 at 23:52, <konrad.wilk@oracle.com> wrote:
> > @@ -374,7 +376,18 @@ static int move_payload(struct payload *payload, struct livepatch_elf *elf)
> >                          elf->name, elf->sec[i].name, elf->sec[i].load_addr);
> >              }
> >              else
> > -                memset(elf->sec[i].load_addr, 0, elf->sec[i].sec->sh_size);
> > +            {
> > +                /* We expect only one BSS. */
> > +                if ( payload->bss )
> > +                {
> > +                    rc = -EINVAL;
> 
> -EOPNOTSUPP according to e.g. the only- one-symbol-table code.

Thanks!
> 
> > +                    goto out;
> > +                }
> > +                payload->bss = elf->sec[i].load_addr;
> > +                payload->bss_size = elf->sec[i].sec->sh_size;
> > +
> > +                memset(payload->bss, 0, payload->bss_size);
> > +            }
> >          }
> >      }
> >  
> > @@ -1034,6 +1047,9 @@ static int revert_payload(struct payload *data)
> >      list_del_rcu(&data->applied_list);
> >      unregister_virtual_region(&data->region);
> >  
> > +    /* And clear the BSS for subsequent operation. */
> > +    memset(data->bss, 0, data->bss_size);
> 
> Instead of doing it in two places, how about moving this into
> apply_payload()?

I was thinking of it too, but then it occurred to me that between the
'check' -> 'apply' the BSS is left unitialized. And if we ever crash
(right as somebody scheduled the livepatch) one could form the opinion
that it is due to the .bss having garbage. Or more importantly - the
hooks may not have run, but all its values looked like they have been
initialized.

And spend considerable amount of time debugging something which in reality
is not a problem?

Perhaps put it in multiple places :-)

> 
> Jan
> 

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