On Tue, 2015-11-24 at 11:24 -0500, Linda Knippers wrote:
>
> Actually, the spec is pretty clear in this case. If you look at the
> length definition for that table (5-133) it says:
>
> Length in bytes for entire structure.
> The length of this structure is either 32 bytes or 80 bytes. The
> length of the structure can be 32 bytes only if the Number of
> Block Control Windows field has a value of 0.
>
> The structure is 80 bytes but it is legal to have a 32-byte table.
> We hit a similar problem with the original NFIT code. We could
> explicitly check for a size of 32 but we didn't before.
Thanks, I missed that. No objections from me any more :)
>
> > If we make add_tables process only header.length and accept the
> > shortened table, there is nothing to tell future code that the
> > structure
> > that piece of memory is casted to is a truncated one.
> >
> > Thoughts?
>
> If we want to be more paranoid about buggy FW when we're comparing old
> and new tables, we could compare based on the length of the old and
> new
> tables since we have both pieces of information. That would let you
> catch
> the case where a table size changes during a hotplug event or whenever
> the
> _FIT is processed. Since you were comparing based on structure size
> instead
> of header length, I didn't change that.
Agreed this can be incremental work.
>
> -- ljk
> >
> > -Vishal
> >
> ��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
