[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 1/9] livepatch: Clear .bss when payload is reverted
On Wed, Sep 07, 2016 at 02:02:44AM -0600, Jan Beulich wrote: > >>> On 06.09.16 at 18:47, <konrad.wilk@xxxxxxxxxx> wrote: > > On Wed, Aug 24, 2016 at 02:55:21AM -0600, Jan Beulich wrote: > >> >>> On 24.08.16 at 04:22, <konrad.wilk@xxxxxxxxxx> wrote: > >> > --- a/xen/common/livepatch.c > >> > +++ b/xen/common/livepatch.c > >> > @@ -70,6 +70,9 @@ struct payload { > >> > unsigned int nsyms; /* Nr of entries in .strtab > >> > and symbols. */ > >> > struct livepatch_build_id id; /* > >> > ELFNOTE_DESC(.note.gnu.build-id) of the payload. */ > >> > struct livepatch_build_id dep; /* > >> > ELFNOTE_DESC(.livepatch.depends). */ > >> > + void **bss; /* .bss's of the payload. */ > >> > + size_t *bss_size; /* and their sizes. */ > >> > >> Is size_t wide enough in the extreme case? Perhaps yes, because I > >> don't think we'll ever load 64-bit ELF on a 32-bit platform. > > > > Nonethless having a huge .bss is a kind of extreme? Perhaps we should > > have an seperate patch that checks the SHT_NOBITS and disallows .bss's > > bigger than say 2MB? > > Well, the extra check certainly wouldn't hurt, but I think before > hitting the size_t limit you'd run out of address space to place > the payload in (as that's iirc a less than 1Gb area). True. And on ARM 32|64 even smaller (2MB). Let me force an even smaller width type - say 'unsigned int'. > > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |