[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Richard Henderson
Subject: Re: [PATCH v10 7/8] linux-user/elfload: Parse NT_GNU_PROPERTY_TYPE_0 notes
Date: Thu, 8 Oct 2020 12:13:35 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

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

> (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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]