| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 30 Jan 2020 12:04:54 -0800
From: "H.J. Lu" <hjl.tools@...il.com>
To: Kees Cook <keescook@...omium.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Andy Lutomirski <luto@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Thomas Lendacky <Thomas.Lendacky@....com>,
Sami Tolvanen <samitolvanen@...gle.com>,
Heiko Carstens <heiko.carstens@...ibm.com>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H . Peter Anvin" <hpa@...or.com>,
"the arch/x86 maintainers" <x86@...nel.org>,
Yu-cheng Yu <yu-cheng.yu@...el.com>
Subject: Re: [PATCH 2/2] x86: Discard .note.gnu.property sections in vmlinux
On Thu, Jan 30, 2020 at 11:51 AM Kees Cook <keescook@...omium.org> 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 <keescook@...omium.org> 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@...-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@...-skx-1 linux]$
Without my patch,
[hjl@...-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@...-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.
Powered by blists - more mailing lists