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:
> > This is a more robust way of preventing DoS problems by bad images
> > than attempting to prove, for each of the (sometimes rather deeply
> > nested) loops, that the total work is "reasonable".  We bound the
> > notional work by 4x the image size (plus 1M).
> 
> The 4x has been selected arbitrarily, I suppose?

Yes.

> >      uint64_t offset;
> > +    const uint64_t max_size_for_deacc = (1UL << 
> > 63)/ELF_MAX_ITERATION_FACTOR;
> 
> This will need adjustment for 32-bit tool stack builds - did you
> perhaps mean UINT64_C(1), considering the type of the variable?

Oops, yes.  Although it has to be (uint64_t)1 since the tools do not
have UINT64_C.

> Also please add blanks around the / .

Done.

> Hypervisor coding style here please (missing lots of blanks, and the
> opening brace needs to go on its own line). I think there are more
> such style problems further down.

Sorry, I will (try to) fix the style in all the patches.

> And then - would it perhaps make sense to have most of this
> function's body in #ifndef __XEN__, as there's nothing to guard
> against when loading Dom0?

This is a good idea.  If it's OK with you I'll leave the variable
initialisation etc., and simply stub out body of elf_iter_ok_counted.
If you want a more comprehensive approach I can add more #ifdefs.

Thanks,
Ian.

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