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~
