[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 12.12.16 at 17:00, <ian.jackson@xxxxxxxxxxxxx> wrote:
> 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.

Well, I have to confess that I've read the above as max() when
in fact it is min().

> 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.

Considering that overflow here will actually result in a comparably
smaller upper limit, I think this may help overall readability. But with
the above I won't insist on this in any way.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.