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
...
}
which may not be incompatible with note.gnu.property sections. Since
note.gnu.property section in kernel image is unused, this patch discards
.note.gnu.property sections in kernel linker script by adding
/DISCARD/ : {
*(.note.gnu.property)
}
before .notes sections. Since .exit.text and .exit.data sections are
discarded at runtime, it undefines EXIT_TEXT and EXIT_DATA to exclude
.exit.text and .exit.data sections from default discarded sections.
Signed-off-by: H.J. Lu <[email protected]>
Signed-off-by: Yu-cheng Yu <[email protected]>
---
arch/x86/kernel/vmlinux.lds.S | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 3a1a819da137..6c6cc26b0177 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -150,6 +150,11 @@ SECTIONS
_etext = .;
. = ALIGN(PAGE_SIZE);
+ /* .note.gnu.property sections should be discarded */
+ /DISCARD/ : {
+ *(.note.gnu.property)
+ }
+
X86_ALIGN_RODATA_BEGIN
RO_DATA(PAGE_SIZE)
X86_ALIGN_RODATA_END
@@ -413,6 +418,12 @@ SECTIONS
STABS_DEBUG
DWARF_DEBUG
+ /* Sections to be discarded. EXIT_TEXT and EXIT_DATA discard at runtime.
+ * not link time. */
+#undef EXIT_TEXT
+#define EXIT_TEXT
+#undef EXIT_DATA
+#define EXIT_DATA
DISCARDS
/DISCARD/ : {
*(.eh_frame)
--
2.24.1
On Fri, Jan 24, 2020 at 10:18:19AM -0800, H.J. Lu wrote:
> 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
> ...
> }
>
> which may not be incompatible with note.gnu.property sections. Since
> note.gnu.property section in kernel image is unused, this patch discards
> .note.gnu.property sections in kernel linker script by adding
>
> /DISCARD/ : {
> *(.note.gnu.property)
> }
I think this is happening in the wrong place? Shouldn't this be in the
DISCARDS macro in include/asm-generic/vmlinux.lds.h instead?
> before .notes sections. Since .exit.text and .exit.data sections are
> discarded at runtime, it undefines EXIT_TEXT and EXIT_DATA to exclude
> .exit.text and .exit.data sections from default discarded sections.
This looks like a separate issue (though maybe related to DISCARDS)?
-Kees
>
> Signed-off-by: H.J. Lu <[email protected]>
> Signed-off-by: Yu-cheng Yu <[email protected]>
> ---
> arch/x86/kernel/vmlinux.lds.S | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
> index 3a1a819da137..6c6cc26b0177 100644
> --- a/arch/x86/kernel/vmlinux.lds.S
> +++ b/arch/x86/kernel/vmlinux.lds.S
> @@ -150,6 +150,11 @@ SECTIONS
> _etext = .;
> . = ALIGN(PAGE_SIZE);
>
> + /* .note.gnu.property sections should be discarded */
> + /DISCARD/ : {
> + *(.note.gnu.property)
> + }
> +
> X86_ALIGN_RODATA_BEGIN
> RO_DATA(PAGE_SIZE)
> X86_ALIGN_RODATA_END
> @@ -413,6 +418,12 @@ SECTIONS
> STABS_DEBUG
> DWARF_DEBUG
>
> + /* Sections to be discarded. EXIT_TEXT and EXIT_DATA discard at runtime.
> + * not link time. */
> +#undef EXIT_TEXT
> +#define EXIT_TEXT
> +#undef EXIT_DATA
> +#define EXIT_DATA
> DISCARDS
> /DISCARD/ : {
> *(.eh_frame)
> --
> 2.24.1
>
--
Kees Cook
On Mon, Jan 27, 2020 at 3:34 PM Kees Cook <[email protected]> wrote:
>
> On Fri, Jan 24, 2020 at 10:18:19AM -0800, H.J. Lu wrote:
> > 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
> > ...
> > }
> >
> > which may not be incompatible with note.gnu.property sections. Since
> > note.gnu.property section in kernel image is unused, this patch discards
> > .note.gnu.property sections in kernel linker script by adding
> >
> > /DISCARD/ : {
> > *(.note.gnu.property)
> > }
>
> I think this is happening in the wrong place? Shouldn't this be in the
> DISCARDS macro in include/asm-generic/vmlinux.lds.h instead?
Please read my commit message closely. We can't discard .note.gnu.property
sections by adding .note.gnu.property to default discarded sections
since default
discarded sections are placed AFTER .notes sections in x86 kernel
linker scripts.
> > before .notes sections. Since .exit.text and .exit.data sections are
> > discarded at runtime, it undefines EXIT_TEXT and EXIT_DATA to exclude
> > .exit.text and .exit.data sections from default discarded sections.
>
> This looks like a separate issue (though maybe related to DISCARDS)?
Here is the updated patch without EXIT_TEXT and EXIT_DATA change.
I will submit a separate patch for it.
Thanks.
--
H.J.
On Thu, Jan 30, 2020 at 09:51:38AM -0800, H.J. Lu wrote:
> On Mon, Jan 27, 2020 at 3:34 PM Kees Cook <[email protected]> wrote:
> >
> > On Fri, Jan 24, 2020 at 10:18:19AM -0800, H.J. Lu wrote:
> > > 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
> > > ...
> > > }
> > >
> > > which may not be incompatible with note.gnu.property sections. Since
I don't understand this. "may not be incompatible"? Is there an error
generated? If so, what does it look like?
> > > note.gnu.property section in kernel image is unused, this patch discards
> > > .note.gnu.property sections in kernel linker script by adding
> > >
> > > /DISCARD/ : {
> > > *(.note.gnu.property)
> > > }
> >
> > I think this is happening in the wrong place? Shouldn't this be in the
> > DISCARDS macro in include/asm-generic/vmlinux.lds.h instead?
>
> Please read my commit message closely. We can't discard .note.gnu.property
> sections by adding .note.gnu.property to default discarded sections
> since default
> discarded sections are placed AFTER .notes sections in x86 kernel
> linker scripts.
I see what you mean now, /DISCARD/ happens after the NOTES macro (now in
the RO_DATA macro). To this end, I think this should be in
include/asm-generic/vmlinux.lds.h in the NOTES macro? It's x86-specific
right now, but why not make this future-proof?
I'd like to avoid as much arch-specific linker stuff as we can. I spent
a lot of time trying to clean up NOTES specifically. :)
> + /* .note.gnu.property sections should be discarded */
This comment should say _why_ -- the script already shows _what_ is
happening...
> + /DISCARD/ : {
> + *(.note.gnu.property)
> + }
-Kees
--
Kees Cook
On Thu, Jan 30, 2020 at 11:51 AM Kees Cook <[email protected]> wrote:
>
> On Thu, Jan 30, 2020 at 09:51:38AM -0800, H.J. Lu wrote:
> > On Mon, Jan 27, 2020 at 3:34 PM Kees Cook <[email protected]> wrote:
> > >
> > > On Fri, Jan 24, 2020 at 10:18:19AM -0800, H.J. Lu wrote:
> > > > 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
> > > > ...
> > > > }
> > > >
> > > > which may not be incompatible with note.gnu.property sections. Since
>
> 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]$
> > > > note.gnu.property section in kernel image is unused, this patch discards
> > > > .note.gnu.property sections in kernel linker script by adding
> > > >
> > > > /DISCARD/ : {
> > > > *(.note.gnu.property)
> > > > }
> > >
> > > I think this is happening in the wrong place? Shouldn't this be in the
> > > DISCARDS macro in include/asm-generic/vmlinux.lds.h instead?
> >
> > Please read my commit message closely. We can't discard .note.gnu.property
> > sections by adding .note.gnu.property to default discarded sections
> > since default
> > discarded sections are placed AFTER .notes sections in x86 kernel
> > linker scripts.
>
> I see what you mean now, /DISCARD/ happens after the NOTES macro (now in
> the RO_DATA macro). To this end, I think this should be in
> include/asm-generic/vmlinux.lds.h in the NOTES macro? It's x86-specific
> right now, but why not make this future-proof?
I am trying to avoid touching generic parts. I will give it a try.
> I'd like to avoid as much arch-specific linker stuff as we can. I spent
> a lot of time trying to clean up NOTES specifically. :)
>
> > + /* .note.gnu.property sections should be discarded */
>
> This comment should say _why_ -- the script already shows _what_ is
> happening...
I will update comments.
> > + /DISCARD/ : {
> > + *(.note.gnu.property)
> > + }
>
Thanks.
--
H.J.
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?
--
Kees Cook
On Thu, Jan 30, 2020 at 12:08 PM Kees Cook <[email protected]> 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.
--
H.J.
On Thu, Jan 30, 2020 at 12:20 PM H.J. Lu <[email protected]> wrote:
>
> On Thu, Jan 30, 2020 at 12:08 PM Kees Cook <[email protected]> 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.
On Thu, Jan 30, 2020 at 12:20:30PM -0800, H.J. Lu wrote:
> On Thu, Jan 30, 2020 at 12:08 PM Kees Cook <[email protected]> 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:
typo: signle -> single
>
> 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:
Ah-ha! Okay, thanks for this detail.
>
> [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.
Okay, I'm convinced. If we ever DO need it, it seems the solution would
be to make the regular .note 8 byte aligned...
Thanks for the extra details!
-Kees
--
Kees Cook
On Thu, Jan 30, 2020 at 12:48:38PM -0800, H.J. Lu wrote:
> Here is a patch to discard .note.gnu.property sections in generic NOTES.
Thanks! This looks good, though please send not as an attachment. :)
Also, one more nit: the comment style should be:
/*
* First line of text, blah blah ...
* ... blah blah, end of text.
*/
--
Kees Cook
On Thu, Jan 30, 2020 at 02:43:37PM -0800, H.J. Lu wrote:
> 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
> kernel linker script only contains a single 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
> ...
> }
>
> The NOTE segment generated by kernel linker script is aligned to 4 bytes.
> But .note.gnu.property section must be aligned to 8 bytes on x86-64 and
> we get
>
> [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]$
>
> Since note.gnu.property section in kernel image is never used, this patch
> discards .note.gnu.property sections in kernel linker script by adding
>
> /DISCARD/ : {
> *(.note.gnu.property)
> }
>
> before kernel NOTE segment in generic NOTES.
>
> Signed-off-by: H.J. Lu <[email protected]>
Thanks!
Reviewed-by: Kees Cook <[email protected]>
-Kees
> ---
> include/asm-generic/vmlinux.lds.h | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index 6b943fb8c5fd..6659a7c07c84 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -818,7 +818,14 @@
> #define TRACEDATA
> #endif
>
> +/*
> + * Discard .note.gnu.property sections which are unused and have
> + * different alignment requirement from kernel note sections.
> + */
> #define NOTES \
> + /DISCARD/ : { \
> + *(.note.gnu.property) \
> + } \
> .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
> __start_notes = .; \
> KEEP(*(.note.*)) \
> --
> 2.24.1
>
--
Kees Cook