Re: [Xen-devel] [PATCH 1/8] libelf: loop safety: Introduce elf_iter_ok and elf_strcmp_safe

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Jan Beulich writes ("Re: [PATCH 1/8] libelf: loop safety: Introduce elf_iter_ok 
and elf_strcmp_safe"):
> On 09.12.16 at 16:44, <ian.jackson@xxxxxxxxxxxxx> wrote:
> > +    const uint64_t max_size_for_deacc = (1UL << 
> > 63)/ELF_MAX_ITERATION_FACTOR;
...
> > +    elf->iteration_deaccumulator = 1024*1024 +
> > +        (size > max_size_for_deacc ? max_size_for_deacc : size)
> > +        * ELF_MAX_ITERATION_FACTOR;        
> 
> One more question here: Is this useful at all? You're allowing
> for approximately 2**63 accounted operations - how big does
> an image need to be to actually break this limit? XSA-25 already
> limited image sizes to 1Gb (but I do understand that the
> guarding here is also against e.g. redundant loading of the
> same bits through multiple program header table entries).
> 
> And how long will it take you to reach that limit (and to cause
> elf->broken to be set)? With 1ns per accounted operation,
> that'll be on the order of 270 years. Am I missing something
> here?

I'm not sure of your point.

Mostly I allow for 4x the size of the image, plus a fixed constant of
1M operations.

The max_size_for_deacc part is necessary because otherwise the
calculation "size * ELF_MAX_ITERATION_FACTOR" might overflow.  It
seems unreasonable to simply allow that overflow to occur.  But if it
is causing confusion we could do that.  The result would be a low
value for iteration_deaccumulator.

In practice the 1Gby image size limit will prevent this limit from
being reached, but it is distant from this check.

Ian.

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