Re: [PATCH v10 7/8] linux-user/elfload: Parse NT_GNU_PROPERTY_TYPE_0 notes

[Richard Henderson <richard.henderson@linaro.org>]

On 10/8/20 9:02 AM, Peter Maydell wrote:
>> +            if (note[0] != 4 ||                       /* namesz */
>> +                note[1] < 12 ||                       /* descsz */
>> +                note[2] != NT_GNU_PROPERTY_TYPE_0 ||  /* type */
>> +                note[3] != gnu0_magic) {              /* name */
> 
> note[2] and note[3] are both basically magic numbers, AIUI.
> Why do we have a #define for one but we assemble the other
> with a const_le32() expression ?

Because one is defined as a number, and the other is defined as a string.  And
why *that* is, I don't know.  Silliness, perhaps.

> The spec for the .note.gnu.property section (which AIUI is
> https://raw.githubusercontent.com/wiki/hjl-tools/linux-abi/linux-abi-draft.pdf
> ) says that the n_desc (words 4 and up) is an array of program
> properties. There doesn't seem to be any guarantee that there
> is only one entry or that the FEATURE_1_AND entry is the first
> in the list. Don't we need to iterate through the array to find
> matches? This seems to be how the kernel does it:
>  https://elixir.bootlin.com/linux/latest/source/fs/binfmt_elf.c#L786

Hmm.  I missed that change since the first time I looked at the in-flight patch
set.

> (Is it worth adding the infrastructure to parse notes generically
> the way the kernel has? I dunno if we think it's likely we'll
> want to do this for more note types and/or other architectures
> in future, so it might just be pointless complexity.)

I dunno about that either.  I'm not really sure what "generically" would look
like without another exemplar.  I'll look at what else
arch_parse_elf_property() is being used for.


r~