| Message ID | 20210423205159.830854-1-morbo@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64/vdso: Discard .note.gnu.property sections in vDSO | expand |
On Fri, Apr 23, 2021 at 01:51:59PM -0700, Bill Wendling wrote: > The arm64 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 the kernel linker script only contains a single > NOTE segment: > > PHDRS > { > text PT_LOAD FLAGS(5) FILEHDR PHDRS; /* PF_R|PF_X */ > dynamic PT_DYNAMIC FLAGS(4); /* PF_R */ > note PT_NOTE FLAGS(4); /* PF_R */ > } > > The NOTE segment generated by the vDSO linker script is aligned to 4 bytes. > But the .note.gnu.property section must be aligned to 8 bytes on arm64. > > $ readelf -n vdso64.so > > Displaying notes found in: .note > Owner Data size Description > Linux 0x00000004 Unknown note type: (0x00000000) > description data: 06 00 00 00 > readelf: Warning: note with invalid namesz and/or descsz found at offset 0x20 > readelf: Warning: type: 0x78, namesize: 0x00000100, descsize: 0x756e694c, alignment: 8 > > Since the note.gnu.property section in the vDSO is not checked by the > dynamic linker, discard the .note.gnu.property sections in the vDSO. > > Similar to commit 4caffe6a28d31 ("x86/vdso: Discard .note.gnu.property > sections in vDSO"), but for arm64. > > Signed-off-by: Bill Wendling <morbo@google.com> Seems good to me. If we ever need the BTI markings, etc, for the vDSO, we can revisit it then. Reviewed-by: Kees Cook <keescook@chromium.org> -Kees
On Wed, 28 Apr 2021 at 00:58, Kees Cook <keescook@chromium.org> wrote: > > On Fri, Apr 23, 2021 at 01:51:59PM -0700, Bill Wendling wrote: > > The arm64 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 the kernel linker script only contains a single > > NOTE segment: > > > > PHDRS > > { > > text PT_LOAD FLAGS(5) FILEHDR PHDRS; /* PF_R|PF_X */ > > dynamic PT_DYNAMIC FLAGS(4); /* PF_R */ > > note PT_NOTE FLAGS(4); /* PF_R */ > > } > > > > The NOTE segment generated by the vDSO linker script is aligned to 4 bytes. > > But the .note.gnu.property section must be aligned to 8 bytes on arm64. > > > > $ readelf -n vdso64.so > > > > Displaying notes found in: .note > > Owner Data size Description > > Linux 0x00000004 Unknown note type: (0x00000000) > > description data: 06 00 00 00 > > readelf: Warning: note with invalid namesz and/or descsz found at offset 0x20 > > readelf: Warning: type: 0x78, namesize: 0x00000100, descsize: 0x756e694c, alignment: 8 > > > > Since the note.gnu.property section in the vDSO is not checked by the > > dynamic linker, discard the .note.gnu.property sections in the vDSO. > > > > Similar to commit 4caffe6a28d31 ("x86/vdso: Discard .note.gnu.property > > sections in vDSO"), but for arm64. > > > > Signed-off-by: Bill Wendling <morbo@google.com> > > Seems good to me. If we ever need the BTI markings, etc, for the vDSO, > we can revisit it then. > > Reviewed-by: Kees Cook <keescook@chromium.org> > Acked-by: Ard Biesheuvel <ardb@kernel.org>
On Fri, Apr 23, 2021 at 01:51:59PM -0700, Bill Wendling wrote: > The arm64 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 the kernel linker script only contains a single > NOTE segment: > > PHDRS > { > text PT_LOAD FLAGS(5) FILEHDR PHDRS; /* PF_R|PF_X */ > dynamic PT_DYNAMIC FLAGS(4); /* PF_R */ > note PT_NOTE FLAGS(4); /* PF_R */ > } > > The NOTE segment generated by the vDSO linker script is aligned to 4 bytes. > But the .note.gnu.property section must be aligned to 8 bytes on arm64. > > $ readelf -n vdso64.so > > Displaying notes found in: .note > Owner Data size Description > Linux 0x00000004 Unknown note type: (0x00000000) > description data: 06 00 00 00 > readelf: Warning: note with invalid namesz and/or descsz found at offset 0x20 > readelf: Warning: type: 0x78, namesize: 0x00000100, descsize: 0x756e694c, alignment: 8 > > Since the note.gnu.property section in the vDSO is not checked by the > dynamic linker, discard the .note.gnu.property sections in the vDSO. > > Similar to commit 4caffe6a28d31 ("x86/vdso: Discard .note.gnu.property > sections in vDSO"), but for arm64. Can we not instead fix the linker script to preserve the .note.gnu.property, correctly aligned? It doesn't take much space and while we don't use it now, it has the BTI information about the binary. Cc'ing a few others who were involved in the BTI support. > Signed-off-by: Bill Wendling <morbo@google.com> > --- > arch/arm64/kernel/vdso/vdso.lds.S | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/kernel/vdso/vdso.lds.S b/arch/arm64/kernel/vdso/vdso.lds.S > index 61dbb4c838ef..a5e61e09ea92 100644 > --- a/arch/arm64/kernel/vdso/vdso.lds.S > +++ b/arch/arm64/kernel/vdso/vdso.lds.S > @@ -31,6 +31,13 @@ SECTIONS > .gnu.version_d : { *(.gnu.version_d) } > .gnu.version_r : { *(.gnu.version_r) } > > + /* > + * Discard .note.gnu.property sections which are unused and have > + * different alignment requirement from vDSO note sections. > + */ > + /DISCARD/ : { > + *(.note.GNU-stack .note.gnu.property) > + } > .note : { *(.note.*) } :text :note > > . = ALIGN(16); > @@ -48,7 +55,6 @@ SECTIONS > PROVIDE(end = .); > > /DISCARD/ : { > - *(.note.GNU-stack) > *(.data .data.* .gnu.linkonce.d.* .sdata*) > *(.bss .sbss .dynbss .dynsbss) > *(.eh_frame .eh_frame_hdr) > -- > 2.31.1.498.g6c1eba8ee3d-goog
On Wed, Apr 28, 2021 at 06:28:47PM +0100, Catalin Marinas wrote: > On Fri, Apr 23, 2021 at 01:51:59PM -0700, Bill Wendling wrote: > > Since the note.gnu.property section in the vDSO is not checked by the > > dynamic linker, discard the .note.gnu.property sections in the vDSO. > Can we not instead fix the linker script to preserve the > .note.gnu.property, correctly aligned? It doesn't take much space and > while we don't use it now, it has the BTI information about the binary. > Cc'ing a few others who were involved in the BTI support. Not just BTI, we also flag PAC usage in there too and could add other extensions going forwards. While the note isn't actively used by anything right now due to the kernel mapping the vDSO prior to userspace starting it is part of the ABI and something could end up wanting to use it and getting confused if it's not there. It would be much better to fix the alignment issue.
On Wed, Apr 28, 2021 at 10:40 AM Mark Brown <broonie@kernel.org> wrote: > On Wed, Apr 28, 2021 at 06:28:47PM +0100, Catalin Marinas wrote: > > On Fri, Apr 23, 2021 at 01:51:59PM -0700, Bill Wendling wrote: > > > > Since the note.gnu.property section in the vDSO is not checked by the > > > dynamic linker, discard the .note.gnu.property sections in the vDSO. > > > Can we not instead fix the linker script to preserve the > > .note.gnu.property, correctly aligned? It doesn't take much space and > > while we don't use it now, it has the BTI information about the binary. > > > Cc'ing a few others who were involved in the BTI support. > > Not just BTI, we also flag PAC usage in there too and could add other > extensions going forwards. While the note isn't actively used by > anything right now due to the kernel mapping the vDSO prior to userspace > starting it is part of the ABI and something could end up wanting to use > it and getting confused if it's not there. It would be much better to > fix the alignment issue. If there's only one of the 8-byte aligned sections guaranteed, we could place it first in the note. Otherwise, we will have to change the alignment of the note (or somehow merge multiple notes). -bw
On Wed, Apr 28, 2021 at 12:21 PM Bill Wendling <morbo@google.com> wrote: > On Wed, Apr 28, 2021 at 10:40 AM Mark Brown <broonie@kernel.org> wrote: > > On Wed, Apr 28, 2021 at 06:28:47PM +0100, Catalin Marinas wrote: > > > On Fri, Apr 23, 2021 at 01:51:59PM -0700, Bill Wendling wrote: > > > > > > Since the note.gnu.property section in the vDSO is not checked by the > > > > dynamic linker, discard the .note.gnu.property sections in the vDSO. > > > > > Can we not instead fix the linker script to preserve the > > > .note.gnu.property, correctly aligned? It doesn't take much space and > > > while we don't use it now, it has the BTI information about the binary. > > > > > Cc'ing a few others who were involved in the BTI support. > > > > Not just BTI, we also flag PAC usage in there too and could add other > > extensions going forwards. While the note isn't actively used by > > anything right now due to the kernel mapping the vDSO prior to userspace > > starting it is part of the ABI and something could end up wanting to use > > it and getting confused if it's not there. It would be much better to > > fix the alignment issue. > > If there's only one of the 8-byte aligned sections guaranteed, we > could place it first in the note. Otherwise, we will have to change > the alignment of the note (or somehow merge multiple notes). > I should have clarified that there's only one *entry* in the .note.gnu.properties section, and if not then is it possible to merge multiple entries into one. (Excuse my ignorance if this is already the case.) -bw
The 04/28/2021 12:31, Bill Wendling wrote: > On Wed, Apr 28, 2021 at 12:21 PM Bill Wendling <morbo@google.com> wrote: > > On Wed, Apr 28, 2021 at 10:40 AM Mark Brown <broonie@kernel.org> wrote: > > > On Wed, Apr 28, 2021 at 06:28:47PM +0100, Catalin Marinas wrote: > > > > On Fri, Apr 23, 2021 at 01:51:59PM -0700, Bill Wendling wrote: > > > > > > > > Since the note.gnu.property section in the vDSO is not checked by the > > > > > dynamic linker, discard the .note.gnu.property sections in the vDSO. > > > > > > > Can we not instead fix the linker script to preserve the > > > > .note.gnu.property, correctly aligned? It doesn't take much space and > > > > while we don't use it now, it has the BTI information about the binary. > > > > > > > Cc'ing a few others who were involved in the BTI support. > > > > > > Not just BTI, we also flag PAC usage in there too and could add other > > > extensions going forwards. While the note isn't actively used by > > > anything right now due to the kernel mapping the vDSO prior to userspace > > > starting it is part of the ABI and something could end up wanting to use > > > it and getting confused if it's not there. It would be much better to > > > fix the alignment issue. > > > > If there's only one of the 8-byte aligned sections guaranteed, we > > could place it first in the note. Otherwise, we will have to change > > the alignment of the note (or somehow merge multiple notes). > > > I should have clarified that there's only one *entry* in the > .note.gnu.properties section, and if not then is it possible to merge > multiple entries into one. (Excuse my ignorance if this is already the > case.) .note.gnu.property should go to PT_GNU_PROPERTY and it should be merged following rules specified in https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI and https://github.com/ARM-software/abi-aa/blob/master/aaelf64/aaelf64.rst#program-property it may also be covered by a (8byte aligned) PT_NOTE, but that's not a requirement on aarch64 (x86 requires it for compatibility with old dynamic linker, but since the vdso is handled specially that may not be relevant either). i don't know how this works in linker scripts.
On Thu, Apr 29, 2021 at 12:55 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote: > The 04/28/2021 12:31, Bill Wendling wrote: > > On Wed, Apr 28, 2021 at 12:21 PM Bill Wendling <morbo@google.com> wrote: > > > On Wed, Apr 28, 2021 at 10:40 AM Mark Brown <broonie@kernel.org> wrote: > > > > On Wed, Apr 28, 2021 at 06:28:47PM +0100, Catalin Marinas wrote: > > > > > On Fri, Apr 23, 2021 at 01:51:59PM -0700, Bill Wendling wrote: > > > > > > > > > > Since the note.gnu.property section in the vDSO is not checked by the > > > > > > dynamic linker, discard the .note.gnu.property sections in the vDSO. > > > > > > > > > Can we not instead fix the linker script to preserve the > > > > > .note.gnu.property, correctly aligned? It doesn't take much space and > > > > > while we don't use it now, it has the BTI information about the binary. > > > > > > > > > Cc'ing a few others who were involved in the BTI support. > > > > > > > > Not just BTI, we also flag PAC usage in there too and could add other > > > > extensions going forwards. While the note isn't actively used by > > > > anything right now due to the kernel mapping the vDSO prior to userspace > > > > starting it is part of the ABI and something could end up wanting to use > > > > it and getting confused if it's not there. It would be much better to > > > > fix the alignment issue. > > > > > > If there's only one of the 8-byte aligned sections guaranteed, we > > > could place it first in the note. Otherwise, we will have to change > > > the alignment of the note (or somehow merge multiple notes). > > > > > I should have clarified that there's only one *entry* in the > > .note.gnu.properties section, and if not then is it possible to merge > > multiple entries into one. (Excuse my ignorance if this is already the > > case.) > > .note.gnu.property should go to PT_GNU_PROPERTY and it > should be merged following rules specified in > https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI > and > https://github.com/ARM-software/abi-aa/blob/master/aaelf64/aaelf64.rst#program-property > > it may also be covered by a (8byte aligned) PT_NOTE, but > that's not a requirement on aarch64 (x86 requires it for > compatibility with old dynamic linker, but since the vdso > is handled specially that may not be relevant either). > > i don't know how this works in linker scripts. This is a potential patch. I haven't had time to test it though. However, it does appear to format the section in the "expected" way, so one's able to grab the build IDs. Thoughts? $ objdump -s -j .note ./arch/arm64/kernel/vdso/vdso.so ./arch/arm64/kernel/vdso/vdso.so: file format elf64-little Contents of section .note: 0288 04000000 10000000 05000000 474e5500 ............GNU. 0298 000000c0 04000000 03000000 00000000 ................ 02a8 06000000 04000000 00000000 4c696e75 ............Linu 02b8 78000000 000a0500 06000000 01000000 x............... 02c8 00010000 4c696e75 78000000 00000000 ....Linux....... 02d8 04000000 14000000 03000000 474e5500 ............GNU. 02e8 958db149 af5156cb 45309896 7a53ae8a ...I.QV.E0..zS.. 02f8 ef34e95c .4.\ diff --git a/arch/arm64/kernel/vdso/vdso.lds.S b/arch/arm64/kernel/vdso/vdso.lds.S index d808ad31e01f..d51e886c6223 100644 --- a/arch/arm64/kernel/vdso/vdso.lds.S +++ b/arch/arm64/kernel/vdso/vdso.lds.S @@ -31,7 +31,13 @@ SECTIONS .gnu.version_d : { *(.gnu.version_d) } .gnu.version_r : { *(.gnu.version_r) } - .note : { *(.note.*) } :text :note + /* + * Add the .note.gnu.property section first, as it's aligned to + * 8-bytes, while other notes are aligned to 4-bytes. + */ + . = ALIGN(8); + + .note : { *(.note.gnu.property) *(.note.*) } :text :note . = ALIGN(16);
The 04/29/2021 02:23, Bill Wendling wrote: > On Thu, Apr 29, 2021 at 12:55 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote: > > The 04/28/2021 12:31, Bill Wendling wrote: > > > On Wed, Apr 28, 2021 at 12:21 PM Bill Wendling <morbo@google.com> wrote: > > > > On Wed, Apr 28, 2021 at 10:40 AM Mark Brown <broonie@kernel.org> wrote: > > > > > On Wed, Apr 28, 2021 at 06:28:47PM +0100, Catalin Marinas wrote: > > > > > > On Fri, Apr 23, 2021 at 01:51:59PM -0700, Bill Wendling wrote: > > > > > > > > > > > > Since the note.gnu.property section in the vDSO is not checked by the > > > > > > > dynamic linker, discard the .note.gnu.property sections in the vDSO. > > > > > > > > > > > Can we not instead fix the linker script to preserve the > > > > > > .note.gnu.property, correctly aligned? It doesn't take much space and > > > > > > while we don't use it now, it has the BTI information about the binary. > > > > > > > > > > > Cc'ing a few others who were involved in the BTI support. > > > > > > > > > > Not just BTI, we also flag PAC usage in there too and could add other > > > > > extensions going forwards. While the note isn't actively used by > > > > > anything right now due to the kernel mapping the vDSO prior to userspace > > > > > starting it is part of the ABI and something could end up wanting to use > > > > > it and getting confused if it's not there. It would be much better to > > > > > fix the alignment issue. > > > > > > > > If there's only one of the 8-byte aligned sections guaranteed, we > > > > could place it first in the note. Otherwise, we will have to change > > > > the alignment of the note (or somehow merge multiple notes). > > > > > > > I should have clarified that there's only one *entry* in the > > > .note.gnu.properties section, and if not then is it possible to merge > > > multiple entries into one. (Excuse my ignorance if this is already the > > > case.) > > > > .note.gnu.property should go to PT_GNU_PROPERTY and it > > should be merged following rules specified in > > https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI > > and > > https://github.com/ARM-software/abi-aa/blob/master/aaelf64/aaelf64.rst#program-property > > > > it may also be covered by a (8byte aligned) PT_NOTE, but > > that's not a requirement on aarch64 (x86 requires it for > > compatibility with old dynamic linker, but since the vdso > > is handled specially that may not be relevant either). > > > > i don't know how this works in linker scripts. > > This is a potential patch. I haven't had time to test it though. > However, it does appear to format the section in the "expected" way, > so one's able to grab the build IDs. Thoughts? please show the program headers. > > $ objdump -s -j .note ./arch/arm64/kernel/vdso/vdso.so > > ./arch/arm64/kernel/vdso/vdso.so: file format elf64-little > > Contents of section .note: > 0288 04000000 10000000 05000000 474e5500 ............GNU. > 0298 000000c0 04000000 03000000 00000000 ................ > 02a8 06000000 04000000 00000000 4c696e75 ............Linu > 02b8 78000000 000a0500 06000000 01000000 x............... > 02c8 00010000 4c696e75 78000000 00000000 ....Linux....... > 02d8 04000000 14000000 03000000 474e5500 ............GNU. > 02e8 958db149 af5156cb 45309896 7a53ae8a ...I.QV.E0..zS.. > 02f8 ef34e95c .4.\ > > diff --git a/arch/arm64/kernel/vdso/vdso.lds.S > b/arch/arm64/kernel/vdso/vdso.lds.S > index d808ad31e01f..d51e886c6223 100644 > --- a/arch/arm64/kernel/vdso/vdso.lds.S > +++ b/arch/arm64/kernel/vdso/vdso.lds.S > @@ -31,7 +31,13 @@ SECTIONS > .gnu.version_d : { *(.gnu.version_d) } > .gnu.version_r : { *(.gnu.version_r) } > > - .note : { *(.note.*) } :text :note > + /* > + * Add the .note.gnu.property section first, as it's aligned to > + * 8-bytes, while other notes are aligned to 4-bytes. > + */ > + . = ALIGN(8); > + > + .note : { *(.note.gnu.property) *(.note.*) } :text :note > > . = ALIGN(16);
On Thu, Apr 29, 2021 at 2:50 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote: > The 04/29/2021 02:23, Bill Wendling wrote: > > On Thu, Apr 29, 2021 at 12:55 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote: > > > The 04/28/2021 12:31, Bill Wendling wrote: > > > > On Wed, Apr 28, 2021 at 12:21 PM Bill Wendling <morbo@google.com> wrote: > > > > > On Wed, Apr 28, 2021 at 10:40 AM Mark Brown <broonie@kernel.org> wrote: > > > > > > On Wed, Apr 28, 2021 at 06:28:47PM +0100, Catalin Marinas wrote: > > > > > > > On Fri, Apr 23, 2021 at 01:51:59PM -0700, Bill Wendling wrote: > > > > > > > > > > > > > > Since the note.gnu.property section in the vDSO is not checked by the > > > > > > > > dynamic linker, discard the .note.gnu.property sections in the vDSO. > > > > > > > > > > > > > Can we not instead fix the linker script to preserve the > > > > > > > .note.gnu.property, correctly aligned? It doesn't take much space and > > > > > > > while we don't use it now, it has the BTI information about the binary. > > > > > > > > > > > > > Cc'ing a few others who were involved in the BTI support. > > > > > > > > > > > > Not just BTI, we also flag PAC usage in there too and could add other > > > > > > extensions going forwards. While the note isn't actively used by > > > > > > anything right now due to the kernel mapping the vDSO prior to userspace > > > > > > starting it is part of the ABI and something could end up wanting to use > > > > > > it and getting confused if it's not there. It would be much better to > > > > > > fix the alignment issue. > > > > > > > > > > If there's only one of the 8-byte aligned sections guaranteed, we > > > > > could place it first in the note. Otherwise, we will have to change > > > > > the alignment of the note (or somehow merge multiple notes). > > > > > > > > > I should have clarified that there's only one *entry* in the > > > > .note.gnu.properties section, and if not then is it possible to merge > > > > multiple entries into one. (Excuse my ignorance if this is already the > > > > case.) > > > > > > .note.gnu.property should go to PT_GNU_PROPERTY and it > > > should be merged following rules specified in > > > https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI > > > and > > > https://github.com/ARM-software/abi-aa/blob/master/aaelf64/aaelf64.rst#program-property > > > > > > it may also be covered by a (8byte aligned) PT_NOTE, but > > > that's not a requirement on aarch64 (x86 requires it for > > > compatibility with old dynamic linker, but since the vdso > > > is handled specially that may not be relevant either). > > > > > > i don't know how this works in linker scripts. > > > > This is a potential patch. I haven't had time to test it though. > > However, it does appear to format the section in the "expected" way, > > so one's able to grab the build IDs. Thoughts? > > > please show the program headers. > $ readelf -lW arch/arm64/kernel/vdso/vdso.so Elf file type is DYN (Shared object file) Entry point 0x300 There are 4 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x000968 0x000968 R E 0x8 DYNAMIC 0x0008a8 0x00000000000008a8 0x00000000000008a8 0x0000c0 0x0000c0 R 0x8 NOTE 0x000288 0x0000000000000288 0x0000000000000288 0x000074 0x000074 R 0x8 GNU_EH_FRAME 0x0008a4 0x00000000000008a4 0x00000000000008a4 0x000000 0x000000 R E 0x1 Section to Segment mapping: Segment Sections... 00 .hash .dynsym .dynstr .gnu.version .gnu.version_d .note .text .eh_frame_hdr .eh_frame .dynamic 01 .dynamic 02 .note 03 .eh_frame_hdr .eh_frame > > > > $ objdump -s -j .note ./arch/arm64/kernel/vdso/vdso.so > > > > ./arch/arm64/kernel/vdso/vdso.so: file format elf64-little > > > > Contents of section .note: > > 0288 04000000 10000000 05000000 474e5500 ............GNU. > > 0298 000000c0 04000000 03000000 00000000 ................ > > 02a8 06000000 04000000 00000000 4c696e75 ............Linu > > 02b8 78000000 000a0500 06000000 01000000 x............... > > 02c8 00010000 4c696e75 78000000 00000000 ....Linux....... > > 02d8 04000000 14000000 03000000 474e5500 ............GNU. > > 02e8 958db149 af5156cb 45309896 7a53ae8a ...I.QV.E0..zS.. > > 02f8 ef34e95c .4.\ > > > > diff --git a/arch/arm64/kernel/vdso/vdso.lds.S > > b/arch/arm64/kernel/vdso/vdso.lds.S > > index d808ad31e01f..d51e886c6223 100644 > > --- a/arch/arm64/kernel/vdso/vdso.lds.S > > +++ b/arch/arm64/kernel/vdso/vdso.lds.S > > @@ -31,7 +31,13 @@ SECTIONS > > .gnu.version_d : { *(.gnu.version_d) } > > .gnu.version_r : { *(.gnu.version_r) } > > > > - .note : { *(.note.*) } :text :note > > + /* > > + * Add the .note.gnu.property section first, as it's aligned to > > + * 8-bytes, while other notes are aligned to 4-bytes. > > + */ > > + . = ALIGN(8); > > + > > + .note : { *(.note.gnu.property) *(.note.*) } :text :note > > > > . = ALIGN(16); > > --
The 04/29/2021 11:52, Bill Wendling wrote: > $ readelf -lW arch/arm64/kernel/vdso/vdso.so > > Elf file type is DYN (Shared object file) > Entry point 0x300 > There are 4 program headers, starting at offset 64 > > Program Headers: > Type Offset VirtAddr PhysAddr > FileSiz MemSiz Flg Align > LOAD 0x000000 0x0000000000000000 0x0000000000000000 > 0x000968 0x000968 R E 0x8 > DYNAMIC 0x0008a8 0x00000000000008a8 0x00000000000008a8 > 0x0000c0 0x0000c0 R 0x8 > NOTE 0x000288 0x0000000000000288 0x0000000000000288 > 0x000074 0x000074 R 0x8 > GNU_EH_FRAME 0x0008a4 0x00000000000008a4 0x00000000000008a4 > 0x000000 0x000000 R E 0x1 this is wrong because the abi specifically says properties are in PT_GNU_PROPERTY, not in PT_NOTE. so the original patch that removes them from notes is fine, but ideally they should be readded under PT_GNU_PROPERTY. (x86 needs it there too, but also needs it under PT_NOTE for historical reasons. ideally the section would have been named other than .note and was not marked as SHF_NOTE, because properties are merged completely differently by the linker than notes, so now linkers have to special case it by section name. properties should have been designed like the .ARM.attributes section except that is not in a load segment and thus has no runtime semantics while the key feature of properties is the runtime semantics. however accessing the program headers of the vdso is not trivial at runtime from user code so dropping the properties might work too, but can bite us in the future depending on how they evolve: the ld.so can look at vdso program headers.)
On Fri, Apr 30, 2021 at 1:17 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote: > The 04/29/2021 11:52, Bill Wendling wrote: > > $ readelf -lW arch/arm64/kernel/vdso/vdso.so > > > > Elf file type is DYN (Shared object file) > > Entry point 0x300 > > There are 4 program headers, starting at offset 64 > > > > Program Headers: > > Type Offset VirtAddr PhysAddr > > FileSiz MemSiz Flg Align > > LOAD 0x000000 0x0000000000000000 0x0000000000000000 > > 0x000968 0x000968 R E 0x8 > > DYNAMIC 0x0008a8 0x00000000000008a8 0x00000000000008a8 > > 0x0000c0 0x0000c0 R 0x8 > > NOTE 0x000288 0x0000000000000288 0x0000000000000288 > > 0x000074 0x000074 R 0x8 > > GNU_EH_FRAME 0x0008a4 0x00000000000008a4 0x00000000000008a4 > > 0x000000 0x000000 R E 0x1 > > this is wrong because the abi specifically says properties > are in PT_GNU_PROPERTY, not in PT_NOTE. > Right. The issue is more complex than this fix is meant for, to be honest. That is, it seems that there needs to be a generalized way of handling the different .note sections. -bw > so the original patch that removes them from notes is fine, > but ideally they should be readded under PT_GNU_PROPERTY. > > (x86 needs it there too, but also needs it under PT_NOTE for > historical reasons. ideally the section would have been named > other than .note and was not marked as SHF_NOTE, because > properties are merged completely differently by the linker > than notes, so now linkers have to special case it by section > name. properties should have been designed like the > .ARM.attributes section except that is not in a load segment > and thus has no runtime semantics while the key feature of > properties is the runtime semantics. however accessing the > program headers of the vdso is not trivial at runtime from > user code so dropping the properties might work too, but can > bite us in the future depending on how they evolve: the ld.so > can look at vdso program headers.)
On Fri, 23 Apr 2021 13:51:59 -0700, Bill Wendling wrote: > The arm64 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 the kernel linker script only contains a single > NOTE segment: > > PHDRS > { > text PT_LOAD FLAGS(5) FILEHDR PHDRS; /* PF_R|PF_X */ > dynamic PT_DYNAMIC FLAGS(4); /* PF_R */ > note PT_NOTE FLAGS(4); /* PF_R */ > } > > [...] Applied to arm64 (for-next/core). Thanks Bill and Szabolcs for clarifying the need for this patch. [1/1] arm64/vdso: Discard .note.gnu.property sections in vDSO https://git.kernel.org/arm64/c/388708028e69
diff --git a/arch/arm64/kernel/vdso/vdso.lds.S b/arch/arm64/kernel/vdso/vdso.lds.S index 61dbb4c838ef..a5e61e09ea92 100644 --- a/arch/arm64/kernel/vdso/vdso.lds.S +++ b/arch/arm64/kernel/vdso/vdso.lds.S @@ -31,6 +31,13 @@ SECTIONS .gnu.version_d : { *(.gnu.version_d) } .gnu.version_r : { *(.gnu.version_r) } + /* + * Discard .note.gnu.property sections which are unused and have + * different alignment requirement from vDSO note sections. + */ + /DISCARD/ : { + *(.note.GNU-stack .note.gnu.property) + } .note : { *(.note.*) } :text :note . = ALIGN(16); @@ -48,7 +55,6 @@ SECTIONS PROVIDE(end = .); /DISCARD/ : { - *(.note.GNU-stack) *(.data .data.* .gnu.linkonce.d.* .sdata*) *(.bss .sbss .dynbss .dynsbss) *(.eh_frame .eh_frame_hdr)
The arm64 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 the kernel linker script only contains a single NOTE segment: PHDRS { text PT_LOAD FLAGS(5) FILEHDR PHDRS; /* PF_R|PF_X */ dynamic PT_DYNAMIC FLAGS(4); /* PF_R */ note PT_NOTE FLAGS(4); /* PF_R */ } The NOTE segment generated by the vDSO linker script is aligned to 4 bytes. But the .note.gnu.property section must be aligned to 8 bytes on arm64. $ readelf -n vdso64.so Displaying notes found in: .note Owner Data size Description Linux 0x00000004 Unknown note type: (0x00000000) description data: 06 00 00 00 readelf: Warning: note with invalid namesz and/or descsz found at offset 0x20 readelf: Warning: type: 0x78, namesize: 0x00000100, descsize: 0x756e694c, alignment: 8 Since the note.gnu.property section in the vDSO is not checked by the dynamic linker, discard the .note.gnu.property sections in the vDSO. Similar to commit 4caffe6a28d31 ("x86/vdso: Discard .note.gnu.property sections in vDSO"), but for arm64. Signed-off-by: Bill Wendling <morbo@google.com> --- arch/arm64/kernel/vdso/vdso.lds.S | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)