All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Thomas Lendacky <Thomas.Lendacky@amd.com>,
	Sami Tolvanen <samitolvanen@google.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H . Peter Anvin" <hpa@zytor.com>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	Yu-cheng Yu <yu-cheng.yu@intel.com>
Subject: [PATCH] Discard .note.gnu.property sections in generic NOTES
Date: Thu, 30 Jan 2020 12:48:38 -0800	[thread overview]
Message-ID: <CAMe9rOpkrPOsymJiBv0i3_Q6hp=fyUYLqBKpOZAHx3d5t54GDA@mail.gmail.com> (raw)
In-Reply-To: <CAMe9rOoU1B8enyoL4-SSQKYLHpevR5yrbp5ewztC=Owr69y2SQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 7826 bytes --]

On Thu, Jan 30, 2020 at 12:20 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Thu, Jan 30, 2020 at 12:08 PM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Thu, Jan 30, 2020 at 12:04:54PM -0800, H.J. Lu wrote:
> > > > I don't understand this. "may not be incompatible"? Is there an error
> > > > generated? If so, what does it look like?
> > >
> > > When -mx86-used-note=yes is passed to assembler, with my patch, I got
> > >
> > > [hjl@gnu-skx-1 linux]$ readelf -n vmlinux
> > >
> > > Displaying notes found in: .notes
> > >   Owner                Data size Description
> > >   Xen                  0x00000006 Unknown note type: (0x00000006)
> > >    description data: 6c 69 6e 75 78 00
> > >   Xen                  0x00000004 Unknown note type: (0x00000007)
> > >    description data: 32 2e 36 00
> > >   Xen                  0x00000008 Unknown note type: (0x00000005)
> > >    description data: 78 65 6e 2d 33 2e 30 00
> > >   Xen                  0x00000008 Unknown note type: (0x00000003)
> > >    description data: 00 00 00 80 ff ff ff ff
> > >   Xen                  0x00000008 Unknown note type: (0x0000000f)
> > >    description data: 00 00 00 00 80 00 00 00
> > >   Xen                  0x00000008 NT_VERSION (version)
> > >    description data: 80 a1 ba 82 ff ff ff ff
> > >   Xen                  0x00000008 NT_ARCH (architecture)
> > >    description data: 00 10 00 81 ff ff ff ff
> > >   Xen                  0x00000029 Unknown note type: (0x0000000a)
> > >    description data: 21 77 72 69 74 61 62 6c 65 5f 70 61 67 65 5f 74
> > > 61 62 6c 65 73 7c 70 61 65 5f 70 67 64 69 72 5f 61 62 6f 76 65 5f 34
> > > 67 62
> > >   Xen                  0x00000004 Unknown note type: (0x00000011)
> > >    description data: 01 88 00 00
> > >   Xen                  0x00000004 Unknown note type: (0x00000009)
> > >    description data: 79 65 73 00
> > >   Xen                  0x00000008 Unknown note type: (0x00000008)
> > >    description data: 67 65 6e 65 72 69 63 00
> > >   Xen                  0x00000010 Unknown note type: (0x0000000d)
> > >    description data: 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
> > >   Xen                  0x00000004 Unknown note type: (0x0000000e)
> > >    description data: 01 00 00 00
> > >   Xen                  0x00000004 Unknown note type: (0x00000010)
> > >    description data: 01 00 00 00
> > >   Xen                  0x00000008 Unknown note type: (0x0000000c)
> > >    description data: 00 00 00 00 00 80 ff ff
> > >   Xen                  0x00000008 Unknown note type: (0x00000004)
> > >    description data: 00 00 00 00 00 00 00 00
> > >   GNU                  0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
> > >     Build ID: 11c73de2922f593e1b35b92ab3c70eaa1a80fa83
> > >   Linux                0x00000018 OPEN
> > >    description data: 35 2e 33 2e 39 2d 32 30 30 2e 30 2e 66 63 33 30
> > > 2e 78 38 36 5f 36 34 00
> > >   Xen                  0x00000008 Unknown note type: (0x00000012)
> > >    description data: 70 04 00 01 00 00 00 00
> > > [hjl@gnu-skx-1 linux]$
> > >
> > > Without my patch,
> > >
> > > [hjl@gnu-skx-1 linux]$ readelf -n vmlinux
> > >
> > > Displaying notes found in: .notes
> > >   Owner                Data size Description
> > >   Xen                  0x00000006 Unknown note type: (0x00000006)
> > >    description data: 6c 69 6e 75 78 00
> > >   Xen                  0x00000004 Unknown note type: (0x00000007)
> > >    description data: 32 2e 36 00
> > >   xen-3.0              0x00000005 Unknown note type: (0x006e6558)
> > >    description data: 08 00 00 00 03
> > > readelf: Warning: note with invalid namesz and/or descsz found at offset 0x50
> > > readelf: Warning:  type: 0xffffffff, namesize: 0x006e6558, descsize:
> > > 0x80000000, alignment: 8
> > > [hjl@gnu-skx-1 linux]$
> >
> > What is the source of this failure? Does readelf need updating instead?
> > Is the linking step producing an invalid section? It seems like
> > discarding the properties isn't the right solution here?
>
> With the command-line option, -mx86-used-note=yes, the x86 assembler
> in binutils 2.32 and above generates a program property note in a note
> section, .note.gnu.property, to encode used x86 ISAs and features.
> But x86 kernel linker script only contains a signle NOTE segment:
>
> PHDRS {
>  text PT_LOAD FLAGS(5);
>  data PT_LOAD FLAGS(6);
>  percpu PT_LOAD FLAGS(6);
>  init PT_LOAD FLAGS(7);
>  note PT_NOTE FLAGS(0);
> }
> SECTIONS
> {
> ...
>  .notes : AT(ADDR(.notes) - 0xffffffff80000000) { __start_notes = .; KEEP(*(.not
> e.*)) __stop_notes = .; } :text :note
> ...
> }
>
> But .note.gnu.property must be 8-byte aligned.  Linker deals with it
> by generating
> 2 PT_NOTE segments, one has 4-byte alignment and the other has 8-byte alignment:
>
> [hjl@gnu-cfl-1 ~]$ readelf -l /usr/local/bin/ld
>
> Elf file type is EXEC (Executable file)
> Entry point 0x404530
> There are 13 program headers, starting at offset 64
>
> Program Headers:
>   Type           Offset             VirtAddr           PhysAddr
>                  FileSiz            MemSiz              Flags  Align
>   PHDR           0x0000000000000040 0x0000000000400040 0x0000000000400040
>                  0x00000000000002d8 0x00000000000002d8  R      0x8
>   INTERP         0x0000000000000318 0x0000000000400318 0x0000000000400318
>                  0x000000000000001c 0x000000000000001c  R      0x1
>       [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
>   LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
>                  0x0000000000002a30 0x0000000000002a30  R      0x1000
>   LOAD           0x0000000000003000 0x0000000000403000 0x0000000000403000
>                  0x00000000000d7b35 0x00000000000d7b35  R E    0x1000
>   LOAD           0x00000000000db000 0x00000000004db000 0x00000000004db000
>                  0x0000000000179248 0x0000000000179248  R      0x1000
>   LOAD           0x0000000000254de0 0x0000000000655de0 0x0000000000655de0
>                  0x00000000000062e8 0x000000000000ba68  RW     0x1000
>   DYNAMIC        0x0000000000254df0 0x0000000000655df0 0x0000000000655df0
>                  0x0000000000000200 0x0000000000000200  RW     0x8
>   NOTE           0x0000000000000338 0x0000000000400338 0x0000000000400338
>                  0x0000000000000030 0x0000000000000030  R      0x8
>   NOTE           0x0000000000000368 0x0000000000400368 0x0000000000400368
>                  0x0000000000000044 0x0000000000000044  R      0x4
>   GNU_PROPERTY   0x0000000000000338 0x0000000000400338 0x0000000000400338
>                  0x0000000000000030 0x0000000000000030  R      0x8
>   GNU_EH_FRAME   0x0000000000233efc 0x0000000000633efc 0x0000000000633efc
>                  0x000000000000478c 0x000000000000478c  R      0x4
>   GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
>                  0x0000000000000000 0x0000000000000000  RW     0x10
>   GNU_RELRO      0x0000000000254de0 0x0000000000655de0 0x0000000000655de0
>                  0x0000000000000220 0x0000000000000220  R      0x1
>
>  Section to Segment mapping:
>   Segment Sections...
>    00
>    01     .interp
>    02     .interp .note.gnu.property .note.gnu.build-id .note.ABI-tag
> .hash .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn
> .rela.plt
>    03     .init .plt .text .fini
>    04     .rodata .eh_frame_hdr .eh_frame
>    05     .init_array .fini_array .dynamic .got .got.plt .data .bss
>    06     .dynamic
>    07     .note.gnu.property
>    08     .note.gnu.build-id .note.ABI-tag
>    09     .note.gnu.property
>    10     .eh_frame_hdr
>    11
>    12     .init_array .fini_array .dynamic .got
> [hjl@gnu-cfl-1 ~]$
>
> Since .note.gnu.property in vmlinux is unused, it can be discarded.
>

Here is a patch to discard .note.gnu.property sections in generic NOTES.

-- 
H.J.

[-- Attachment #2: 0001-Discard-.note.gnu.property-sections-in-generic-NOTES.patch --]
[-- Type: application/x-patch, Size: 2447 bytes --]

  reply	other threads:[~2020-01-30 20:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-24 18:18 [PATCH 0/2] x86: Discard .note.gnu.property sections H.J. Lu
2020-01-24 18:18 ` [PATCH 1/2] x86: Discard .note.gnu.property sections in vDSO H.J. Lu
2020-01-24 18:18 ` [PATCH 2/2] x86: Discard .note.gnu.property sections in vmlinux H.J. Lu
2020-01-27 23:34   ` Kees Cook
2020-01-30 17:51     ` H.J. Lu
2020-01-30 19:51       ` Kees Cook
2020-01-30 20:04         ` H.J. Lu
2020-01-30 20:08           ` Kees Cook
2020-01-30 20:20             ` H.J. Lu
2020-01-30 20:48               ` H.J. Lu [this message]
2020-01-30 22:09                 ` [PATCH] Discard .note.gnu.property sections in generic NOTES Kees Cook
2020-01-30 22:06               ` [PATCH 2/2] x86: Discard .note.gnu.property sections in vmlinux Kees Cook
2020-01-30 22:43 [PATCH] Add RUNTIME_DISCARD_EXIT to generic DISCARDS H.J. Lu
2020-01-30 22:43 ` [PATCH] Discard .note.gnu.property sections in generic NOTES H.J. Lu
2020-01-30 22:52   ` Kees Cook
2020-03-27 12:11 H.J. Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMe9rOpkrPOsymJiBv0i3_Q6hp=fyUYLqBKpOZAHx3d5t54GDA@mail.gmail.com' \
    --to=hjl.tools@gmail.com \
    --cc=Thomas.Lendacky@amd.com \
    --cc=bp@alien8.de \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=samitolvanen@google.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yu-cheng.yu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.