Re: [Xen-devel] [PATCH v3 05/23] xsplice: Add helper elf routines (v4)

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 12/02/16 20:47, Konrad Rzeszutek Wilk wrote:
>>> +struct xsplice_elf_sec *xsplice_elf_sec_by_name(const struct xsplice_elf 
>>> *elf,
>>> +                                                const char *name)
>>> +{
>>> +    unsigned int i;
>>> +
>>> +    for ( i = 0; i < elf->hdr->e_shnum; i++ )
>>> +    {
>>> +        if ( !strcmp(name, elf->sec[i].name) )
>>> +            return &elf->sec[i];
>>> +    }
>>> +
>>> +    return NULL;
>>> +}
>>> +
>>> +static int elf_resolve_sections(struct xsplice_elf *elf, uint8_t *data)
>>> +{
>>> +    struct xsplice_elf_sec *sec;
>>> +    unsigned int i;
>>> +
>>> +    sec = xmalloc_array(struct xsplice_elf_sec, elf->hdr->e_shnum);
>> Presumably there will be some sanity checks done somewhere between the
>> hypercall and here?
> There are checks on it but not the value itself. As in the payload could
> have e_shnum be some astronomical value because of many .sections in the
> file (even the ones we do not use). We could combat that by having
> an whitelist of sections - and:
>  - If the payload has them return -EINVAL.
>  - If the payload has them - ignore them and continue on but instead of
>    using e_shnum use the counted value of the sections we expect?
>
> Preferences?

Anything more than a handful of sections is likely to be a bogus ELF
file.  I would put a hard limit (64 perhaps?).  If we fine a plausible
usecase for that many sections in a patch, we can revisit the logic.

We should bail in any situation where we find a value we don't like,
such as an unknown section.  As this is binary patching Xen, I would
prefer not to take any unnecessary risks.

~Andrew

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