[PATCH] Check multiple NT_GNU_PROPERTY_TYPE_0 notes [BZ #23509]

H.J. Lu hjl.tools@gmail.com
Thu Aug 16 11:39:00 GMT 2018


On Thu, Aug 16, 2018 at 4:28 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 08/15/2018 05:29 PM, H.J. Lu wrote:
>>
>> On Wed, Aug 15, 2018 at 8:25 AM, Florian Weimer <fweimer@redhat.com>
>> wrote:
>>>
>>> On 08/15/2018 05:23 PM, H.J. Lu wrote:
>>>>
>>>>
>>>> On Wed, Aug 15, 2018 at 8:17 AM, Florian Weimer <fweimer@redhat.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 08/14/2018 08:12 PM, H.J. Lu wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> _dl_process_cet_property_note is called on on each PT_NOTE segment.
>>>>>> We must keep searching until we found a PT_NOTE segment with a
>>>>>> NT_GNU_PROPERTY_TYPE_0 note:
>>>>>>
>>>>>>      /* Skip if we have seen a NT_GNU_PROPERTY_TYPE_0 note before.  */
>>>>>>      if (l->l_cet != lc_unknown)
>>>>>>        return;
>>>>>> ...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> What if there are different segments, each one with its own
>>>>> NT_GNU_PROPERTY_TYPE_0?  Wouldn't that point to lack of linker support,
>>>>> too?
>>>>> So that CET needs to be disabled?
>>>>
>>>>
>>>>
>>>> Older linkers puts all NT_GNU_PROPERTY_TYPE_0 notes in one
>>>> .note.gnu.property section.  One can certainly create some random notes
>>>> which look like NT_GNU_PROPERTY_TYPE_0.  I don't think we need to
>>>> check these notes.
>>>
>>>
>>>
>>> I think older BFD ld creates multiple segments.
>>
>>
>> Which version of ld dos that?
>
>
> Examples that got me worried look like this:
>
> $ readelf -l /usr/bin/b5i2iso
>>   NOTE           0x0000000000000334 0x0000000000400334 0x0000000000400334
>                  0x0000000000000020 0x0000000000000020  R      0x4
>   NOTE           0x0000000000000358 0x0000000000400358 0x0000000000400358
>                  0x0000000000000030 0x0000000000000030  R      0x8
>   NOTE           0x0000000000000388 0x0000000000400388 0x0000000000400388
>                  0x0000000000000024 0x0000000000000024  R      0x4
>>    07     .note.ABI-tag
>    08     .note.gnu.property
>    09     .note.gnu.build-id
>> $ rpm -qf /usr/bin/b5i2iso
> AcetoneISO-6.7-26.fc29.x86_64
>
> Per
> <https://kojipkgs.fedoraproject.org//packages/AcetoneISO/6.7/26.fc29/data/logs/x86_64/root.log>,
> this was built with binutils-2.30.90-4.fc29.
>
> I don't know enough about the binutils linker to be certain that allocatable
> SHT_NOTE sections of the same name always go into the same PT_NOTE segment.
> In the example above, the sections weren't split.

Please show the output of "readelf -n".  I believe that all
NT_GNU_PROPERTY_TYPE_0
notes are in a single PT_NOTE segment.  My patch checks each PT_LOAD segment
until a NT_GNU_PROPERTY_TYPE_0 note is found.  If more than one note is found,
it disables CET since the binary was created by the older linker.

BTW, the new linker also creates more than one note:

[hjl@gnu-cfl-1 binutils]$ readelf -ln  /bin/sprof

Elf file type is DYN (Shared object file)
Entry point 0x36d0
There are 12 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000000040 0x0000000000000040
                 0x00000000000002a0 0x00000000000002a0  R      0x8
  INTERP         0x00000000000002e0 0x00000000000002e0 0x00000000000002e0
                 0x000000000000001c 0x000000000000001c  R      0x1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000001708 0x0000000000001708  R      0x1000
  LOAD           0x0000000000002000 0x0000000000002000 0x0000000000002000
                 0x0000000000002fc5 0x0000000000002fc5  R E    0x1000
  LOAD           0x0000000000005000 0x0000000000005000 0x0000000000005000
                 0x0000000000000c30 0x0000000000000c30  R      0x1000
  LOAD           0x0000000000005c70 0x0000000000006c70 0x0000000000006c70
                 0x0000000000000590 0x0000000000000670  RW     0x1000
  DYNAMIC        0x0000000000005dc8 0x0000000000006dc8 0x0000000000006dc8
                 0x0000000000000200 0x0000000000000200  RW     0x8
  NOTE           0x0000000000000300 0x0000000000000300 0x0000000000000300
                 0x0000000000000020 0x0000000000000020  R      0x8
  NOTE           0x0000000000000320 0x0000000000000320 0x0000000000000320
                 0x0000000000000044 0x0000000000000044  R      0x4
  GNU_EH_FRAME   0x00000000000058f0 0x00000000000058f0 0x00000000000058f0
                 0x00000000000000ac 0x00000000000000ac  R      0x4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     0x10
  GNU_RELRO      0x0000000000005c70 0x0000000000006c70 0x0000000000006c70
                 0x0000000000000390 0x0000000000000390  R      0x1

 Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .interp .note.gnu.property .note.ABI-tag .note.gnu.build-id
.hash .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn
.rela.plt
   03     .init .plt .plt.got .plt.sec .text .fini
   04     .rodata .eh_frame_hdr .eh_frame
   05     .init_array .fini_array .data.rel.ro .dynamic .got .got.plt .data .bss
   06     .dynamic
   07     .note.gnu.property
   08     .note.ABI-tag .note.gnu.build-id
   09     .eh_frame_hdr
   10
   11     .init_array .fini_array .data.rel.ro .dynamic .got

Displaying notes found in: .note.gnu.property
  Owner                 Data size Description
  GNU                  0x00000010 NT_GNU_PROPERTY_TYPE_0
      Properties: x86 feature: IBT, SHSTK

Displaying notes found in: .note.ABI-tag
  Owner                 Data size Description
  GNU                  0x00000010 NT_GNU_ABI_TAG (ABI version tag)
    OS: Linux, ABI: 3.2.0

Displaying notes found in: .note.gnu.build-id
  Owner                 Data size Description
  GNU                  0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
    Build ID: 59cb797230842a68fe5d61189f03c50acb9e84bf
[hjl@gnu-cfl-1 binutils]$



-- 
H.J.



More information about the Libc-alpha mailing list