| Message ID | 20180523001939.9431-3-labbott@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, May 22, 2018 at 5:19 PM Laura Abbott <labbott@redhat.com> wrote: > The vDSO is linked separately from the kernel and modules. Ensure it picks > up the comment section, if available. Did you end up preferring this to just sticking the kernel version in a .comment in the vDSO for some reason? -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/22/2018 05:33 PM, Andy Lutomirski wrote: > On Tue, May 22, 2018 at 5:19 PM Laura Abbott <labbott@redhat.com> wrote: > > >> The vDSO is linked separately from the kernel and modules. Ensure it picks >> up the comment section, if available. > > Did you end up preferring this to just sticking the kernel version in a > .comment in the vDSO for some reason? > That's a good idea I hadn't considered. I'll do that for the next version. Thanks, Laura -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/22/2018 05:33 PM, Andy Lutomirski wrote: > On Tue, May 22, 2018 at 5:19 PM Laura Abbott <labbott@redhat.com> wrote: > > >> The vDSO is linked separately from the kernel and modules. Ensure it picks >> up the comment section, if available. > > Did you end up preferring this to just sticking the kernel version in a > .comment in the vDSO for some reason? > Actually I remember now why this is necessary: there is not a simple way to encode a string into a linker file as it has to be spit out byte by byte. The autogeneration was the easiest way to make that happen. Maybe there's some horrific c preprocessing or other generation that could happen but I doubt that's any worse than the generated linker script. Thanks, Laura -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, May 23, 2018 at 3:53 PM Laura Abbott <labbott@redhat.com> wrote: > Actually I remember now why this is necessary: there is not a simple way > to encode a string into a linker file as it has to be spit out byte > by byte. I think you can use the "fill" thing to basically add any random data to a section. So you can do something like . = ALIGN(16); .salt : AT(ADDR(.salt) - LOAD_OFFSET) { LONG(0xffaa5500); . = ALIGN(16); } =0x01234567890abcdef in the lds file, and you'll get a section that looks like this: [torvalds@i7 linux]$ objdump -h vmlinux -j .salt -s vmlinux: file format elf64-x86-64 Sections: Idx Name Size VMA LMA File off Algn 15 .salt 00000010 ffffffff8432b000 000000000432b000 0352b000 2**0 CONTENTS, ALLOC, LOAD, DATA Contents of section .salt: ffffffff8432b000 0055aaff 00123456 7890abcd ef001234 .U....4Vx......4 Now whether that is sufficient for your needs, I dunno. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> On May 23, 2018, at 4:55 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > >> On Wed, May 23, 2018 at 3:53 PM Laura Abbott <labbott@redhat.com> wrote: >> >> Actually I remember now why this is necessary: there is not a simple way >> to encode a string into a linker file as it has to be spit out byte >> by byte. > > I think you can use the "fill" thing to basically add any random data to a > section. > > So you can do something like > > . = ALIGN(16); > .salt : AT(ADDR(.salt) - LOAD_OFFSET) { > LONG(0xffaa5500); > . = ALIGN(16); > } =0x01234567890abcdef > > in the lds file, and you'll get a section that looks like this: > > [torvalds@i7 linux]$ objdump -h vmlinux -j .salt -s > > vmlinux: file format elf64-x86-64 > > Sections: > Idx Name Size VMA LMA File off > Algn > 15 .salt 00000010 ffffffff8432b000 000000000432b000 0352b000 > 2**0 > CONTENTS, ALLOC, LOAD, DATA > Contents of section .salt: > ffffffff8432b000 0055aaff 00123456 7890abcd ef001234 .U....4Vx......4 > > Now whether that is sufficient for your needs, I dunno. > I don’t know whether I’m missing something obvious, but can’t this be in C? asm (“.pushsection \”.comment\”; .ascii \”” WHATEVER “\”; .popsection”); Or the .S equivalent. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2018-05-24 7:53 GMT+09:00 Laura Abbott <labbott@redhat.com>: > On 05/22/2018 05:33 PM, Andy Lutomirski wrote: >> >> On Tue, May 22, 2018 at 5:19 PM Laura Abbott <labbott@redhat.com> wrote: >> >> >>> The vDSO is linked separately from the kernel and modules. Ensure it >>> picks >>> up the comment section, if available. >> >> >> Did you end up preferring this to just sticking the kernel version in a >> .comment in the vDSO for some reason? >> > > Actually I remember now why this is necessary: there is not a simple way > to encode a string into a linker file as it has to be spit out byte > by byte. The autogeneration was the easiest way to make that happen. > Maybe there's some horrific c preprocessing or other generation that > could happen but I doubt that's any worse than the generated linker > script. > I am personally prefer CONFIG option (as you did in v2) to KERNELVERSION. If you use "hex" type instead of "string" type in Kconfig, and LONG() instead of BYTE() in the script script, this can be much simpler, right? config BUILD_ID_SALT hex "Build ID Salt" help ... Then, in scripts/Makefile, define filechk_build-salt.lds { \ echo "SECTIONS {"; \ echo ".comment (INFO) : { LONG($(CONFIG_BUILD_ID_SALT)); }"; \ echo "}"; \ } endef $(obj)/build-salt.lds: $(src)/Makefile FORCE $(call filechk,build-salt.lds) This is now so simple that we can even remove the shell script.
On 05/23/2018 05:06 PM, Linus Torvalds wrote: > > > On Wed, May 23, 2018, 17:01 Andy Lutomirski <luto@amacapital.net <mailto:luto@amacapital.net>> wrote: > > > I don’t know whether I’m missing something obvious, but can’t this be in C? > > > Yes, but I thought Laura wanted to limit it to linker file tricks (this thread has gone on for so long that I've forgotten the details of why). > > Linus > > So we have to update the kernel and every module and the easiest way to do that was the linker script. I was assuming I'd just use the same approach for the vDSO but you're right that there's no reason we can't apply a different technique. I notice there's already a vdso-note.S which adds LINUX_VERSION_CODE as a note. This doesn't include the extra version so it doesn't quite meet our needs. There's no reason why we can't throw something else in there for good measure. Thanks, Laura -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2018-05-24 9:11 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>: > 2018-05-24 7:53 GMT+09:00 Laura Abbott <labbott@redhat.com>: >> On 05/22/2018 05:33 PM, Andy Lutomirski wrote: >>> >>> On Tue, May 22, 2018 at 5:19 PM Laura Abbott <labbott@redhat.com> wrote: >>> >>> >>>> The vDSO is linked separately from the kernel and modules. Ensure it >>>> picks >>>> up the comment section, if available. >>> >>> >>> Did you end up preferring this to just sticking the kernel version in a >>> .comment in the vDSO for some reason? >>> >> >> Actually I remember now why this is necessary: there is not a simple way >> to encode a string into a linker file as it has to be spit out byte >> by byte. The autogeneration was the easiest way to make that happen. >> Maybe there's some horrific c preprocessing or other generation that >> could happen but I doubt that's any worse than the generated linker >> script. >> > > > I am personally prefer CONFIG option (as you did in v2) to KERNELVERSION. > > > If you use "hex" type instead of "string" type in Kconfig, > and LONG() instead of BYTE() in the script script, > this can be much simpler, right? > > > > > > config BUILD_ID_SALT > hex "Build ID Salt" > help > ... > > > > > Then, in scripts/Makefile, > > > define filechk_build-salt.lds > { \ > echo "SECTIONS {"; \ > echo ".comment (INFO) : { LONG($(CONFIG_BUILD_ID_SALT)); }"; \ > echo "}"; \ > } > endef > > $(obj)/build-salt.lds: $(src)/Makefile FORCE > $(call filechk,build-salt.lds) > > > > > This is now so simple that we can even remove the shell script. I had not noticed the comments from Linus and Andy before I posted mine. Maybe, we should not add binary data into the .comment section.
2018-05-23 9:19 GMT+09:00 Laura Abbott <labbott@redhat.com>: > > The vDSO is linked separately from the kernel and modules. Ensure it picks > up the comment section, if available. > > Signed-off-by: Laura Abbott <labbott@redhat.com> > --- > v3: Invoke the generated linker script. The ".." nightmare is pretty > ugly but I didn't see an easier way to pick up the generated file. > That was actually part of my motivation for using an #include since > paths for those are standardized. Maybe, you found a different approach. FWIW, If you use the linker script approach, you could simply use scripts/build-salt.lds instead of $(obj)/../../../../scripts/build-salt.lds
On 05/23/2018 06:43 PM, Masahiro Yamada wrote: > 2018-05-24 9:11 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>: >> 2018-05-24 7:53 GMT+09:00 Laura Abbott <labbott@redhat.com>: >>> On 05/22/2018 05:33 PM, Andy Lutomirski wrote: >>>> >>>> On Tue, May 22, 2018 at 5:19 PM Laura Abbott <labbott@redhat.com> wrote: >>>> >>>> >>>>> The vDSO is linked separately from the kernel and modules. Ensure it >>>>> picks >>>>> up the comment section, if available. >>>> >>>> >>>> Did you end up preferring this to just sticking the kernel version in a >>>> .comment in the vDSO for some reason? >>>> >>> >>> Actually I remember now why this is necessary: there is not a simple way >>> to encode a string into a linker file as it has to be spit out byte >>> by byte. The autogeneration was the easiest way to make that happen. >>> Maybe there's some horrific c preprocessing or other generation that >>> could happen but I doubt that's any worse than the generated linker >>> script. >>> >> >> >> I am personally prefer CONFIG option (as you did in v2) to KERNELVERSION. >> >> >> If you use "hex" type instead of "string" type in Kconfig, >> and LONG() instead of BYTE() in the script script, >> this can be much simpler, right? >> >> >> >> >> >> config BUILD_ID_SALT >> hex "Build ID Salt" >> help >> ... >> >> >> >> >> Then, in scripts/Makefile, >> >> >> define filechk_build-salt.lds >> { \ >> echo "SECTIONS {"; \ >> echo ".comment (INFO) : { LONG($(CONFIG_BUILD_ID_SALT)); }"; \ >> echo "}"; \ >> } >> endef >> >> $(obj)/build-salt.lds: $(src)/Makefile FORCE >> $(call filechk,build-salt.lds) >> >> >> >> >> This is now so simple that we can even remove the shell script. > > > > I had not noticed the comments from Linus and Andy > before I posted mine. > > > Maybe, we should not add binary data into the .comment section. > > > The comments from Linus and Andy apply to the vDSO but I don't think they work for the kernel/modules. We need something that can apply to every module and the kernel and the linker script seems like easiest way to do that. The vDSO is a self-contained binary so it makes sense to not use the linker script there and instead throw something in one of the existing files. I'm kind of iffy about making the build-id salt a hex string since that requires bit more work to generate. I'll experiment in a new version. Thanks, Laura -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile index d998a487c9b1..f54aa97dc9f0 100644 --- a/arch/x86/entry/vdso/Makefile +++ b/arch/x86/entry/vdso/Makefile @@ -162,7 +162,9 @@ $(obj)/vdso32.so.dbg: FORCE \ quiet_cmd_vdso = VDSO $@ cmd_vdso = $(CC) -nostdlib -o $@ \ $(VDSO_LDFLAGS) $(VDSO_LDFLAGS_$(filter %.lds,$(^F))) \ - -Wl,-T,$(filter %.lds,$^) $(filter %.o,$^) && \ + -Wl,-T,$(filter %.lds,$^) \ + -Wl,-T$(obj)/../../../../scripts/build-salt.lds \ + $(filter %.o,$^) && \ sh $(srctree)/$(src)/checkundef.sh '$(NM)' '$@' VDSO_LDFLAGS = -fPIC -shared $(call cc-ldoption, -Wl$(comma)--hash-style=both) \
The vDSO is linked separately from the kernel and modules. Ensure it picks up the comment section, if available. Signed-off-by: Laura Abbott <labbott@redhat.com> --- v3: Invoke the generated linker script. The ".." nightmare is pretty ugly but I didn't see an easier way to pick up the generated file. That was actually part of my motivation for using an #include since paths for those are standardized. --- arch/x86/entry/vdso/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)