[SeaBIOS] Re: recent ld built for x86_64 fails to accept 16bit code as input (seabios build)
11.07.2020 03:08, Kevin O'Connor wrote: [] > As for the particular workaround, "-z allowexec" generates a warning > on current versions of ld. Given that, for SeaBIOS, my first reaction > would probably be to change the SeaBIOS build to unconditionally clear > the flag in the intermediate binary than to deploy a more complicated > ld version check to set the given command-line flag. I'd like to give > that some more thought though. Can't seabios use the way suggested by Andreas Schwab, namely .incbin assembler instruction? /mjt ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: recent ld built for x86_64 fails to accept 16bit code as input (seabios build)
On 2020-07-10, Kevin O'Connor wrote: On Fri, Jul 10, 2020 at 11:58:06AM +0100, Nick Clifton wrote: Hi Guys, I have just updated PR 26047 with a suggested patch which I think could resolve this situation. (Patch attached here as well in order to save time). It adds a new linker command line option: -z allowexec which will disable the warnings about linking in executable files. The default is still to have these warnings as I think that in most cases this behaviour makes sense. Will this solve the problem for you ? Hi Nick, Thanks for looking at this. I think the main issue is going to be the breaking of existing software builds. In particular, as distros pull in the new version of binutils, they'll run into errors building their current version of SeaBIOS. Even if we update SeaBIOS today, it will be some time before the distros will pull that change in. It'll also be a problem for those trying to build older versions of SeaBIOS on newer toolchains. Unless I'm missing something, this will also be a problem for those building recent versions of the Linux kernel. It's build used this ability of ld up until a few months ago (see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=90ceddcb495008ac8ba7a3dce297841efcd7d584 ). Although the latest Linux has changed, building older versions is fairly common. There is no problem (reject linking ET_EXEC as input) for 5.4, 5.6 and HEAD. The fixes are in stable trees. [PATCH 5.4 007/134] bpf: Support llvm-objcopy for vmlinux BTF [PATCH 5.6 012/161] bpf: Support llvm-objcopy for vmlinux BTF I haven't tested 5.2 (the first major release with potentially problematic BTF commit) but if someone worries about 5.2 linkability with GNU ld 2.35, the error can be downgraded to a warning. It's unclear to me if there are other common packages that use this ability of ld. I don't think so. There is no FreeBSD package which has been marked LLD_UNSAFE for the sole reason that older GNU ld accepts ET_EXEC while LLD rejects ET_EXEC. Among the tens of thousands of ports, % rg -l LLD_UNSAFE 75 In the future there may be more ET_* types. I don't think linking them will be correct/intended https://groups.google.com/forum/#!topic/generic-abi/tJq7anc6WKs "RFC: Add ET_DEBUG" (the RFC has not been accepted but OSes can freely use ET_GNU_* ) The opinion in my other message (https://sourceware.org/pipermail/binutils/2020-July/112283.html ) stands. allowexec will not be a suitable option name. For seabios and Linux 5.2 (this major release only), a linker warning should not hurt. In a future release of GNU ld, the warning can be upgraded to an error. ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: recent ld built for x86_64 fails to accept 16bit code as input (seabios build)
On Fri, Jul 10, 2020 at 11:58:06AM +0100, Nick Clifton wrote: > Hi Guys, > > I have just updated PR 26047 with a suggested patch which I think could > resolve > this situation. (Patch attached here as well in order to save time). It > adds > a new linker command line option: -z allowexec which will disable the > warnings > about linking in executable files. The default is still to have these > warnings > as I think that in most cases this behaviour makes sense. > > Will this solve the problem for you ? Hi Nick, Thanks for looking at this. I think the main issue is going to be the breaking of existing software builds. In particular, as distros pull in the new version of binutils, they'll run into errors building their current version of SeaBIOS. Even if we update SeaBIOS today, it will be some time before the distros will pull that change in. It'll also be a problem for those trying to build older versions of SeaBIOS on newer toolchains. Unless I'm missing something, this will also be a problem for those building recent versions of the Linux kernel. It's build used this ability of ld up until a few months ago (see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=90ceddcb495008ac8ba7a3dce297841efcd7d584 ). Although the latest Linux has changed, building older versions is fairly common. It's unclear to me if there are other common packages that use this ability of ld. Also, you mentioned "which will disable the warnings about linking in executable files". I thought PR 26047 created a fatal error in this situation. Is the proposed change to make the error a warning or am I missing something? As for the particular workaround, "-z allowexec" generates a warning on current versions of ld. Given that, for SeaBIOS, my first reaction would probably be to change the SeaBIOS build to unconditionally clear the flag in the intermediate binary than to deploy a more complicated ld version check to set the given command-line flag. I'd like to give that some more thought though. Thanks again, -Kevin ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: recent ld built for x86_64 fails to accept 16bit code as input (seabios build)
Hi Guys, I have just updated PR 26047 with a suggested patch which I think could resolve this situation. (Patch attached here as well in order to save time). It adds a new linker command line option: -z allowexec which will disable the warnings about linking in executable files. The default is still to have these warnings as I think that in most cases this behaviour makes sense. Will this solve the problem for you ? Cheers Nick diff --git a/include/bfdlink.h b/include/bfdlink.h index 7163433383..d9c0fe6367 100644 --- a/include/bfdlink.h +++ b/include/bfdlink.h @@ -520,6 +520,10 @@ struct bfd_link_info the linker. */ unsigned int non_contiguous_regions_warnings : 1; + /* TRUE if "-z allowexec" has been set in order to allow use of + executable files (ELF type ET_EXEC) as inputs to a link. */ + unsigned int allow_exec_input : 1; + /* Char that may appear as the first char of a symbol, but should be skipped (like symbol_leading_char) when looking up symbols in wrap_hash. Used by PowerPC Linux for 'dot' symbols. */ diff --git a/ld/NEWS b/ld/NEWS index eb2cff12ea..544d1324e1 100644 --- a/ld/NEWS +++ b/ld/NEWS @@ -1,5 +1,8 @@ -*- text -*- +~ Add -z allowexec command line option to permit the use of executable files as + inputs to a link. + Changes in 2.35: * X86 NaCl target support is removed. diff --git a/ld/emultempl/elf.em b/ld/emultempl/elf.em index 356f34538b..538f8a096c 100644 --- a/ld/emultempl/elf.em +++ b/ld/emultempl/elf.em @@ -708,6 +708,10 @@ fragmentlink.next) + /* PR 26047: Do not allow executable files to be used as inputs + to the link unless specifically requested by the user. */ + if (!link_info.allow_exec_input) { - if (elf_tdata (abfd) != NULL - && elf_tdata (abfd)->elf_header != NULL - /* FIXME: Maybe check for other non-supportable types as well ? */ - && elf_tdata (abfd)->elf_header->e_type == ET_EXEC) - einfo (_("%F%P: cannot use executable file '%pB' as input to a link\n"), - abfd); + for (abfd = link_info.input_bfds; abfd; abfd = abfd->link.next) + { + if (elf_tdata (abfd) != NULL + && elf_tdata (abfd)->elf_header != NULL + /* FIXME: Maybe check for other non-supportable types as well ? */ + && elf_tdata (abfd)->elf_header->e_type == ET_EXEC) + einfo (_("%F%P: cannot use executable file '%pB' as input to a link\n"), + abfd); + } } if (bfd_link_relocatable (&link_info)) @@ -1078,12 +1082,13 @@ ldelf_after_open (int use_libpath, int native, int is_linux, int is_freebsd, { int type = 0; - if (bfd_link_executable (& link_info) + /* PR 26047: Do not allow executable files to be used as inputs + to the link unless specifically requested by the user. */ + if (!link_info.allow_exec_input + && bfd_link_executable (& link_info) && elf_tdata (abfd)->elf_header->e_type == ET_EXEC) - { - einfo (_("%F%P: cannot use executable file '%pB' as input to a link\n"), - abfd); - } + einfo (_("%F%P: cannot use executable file '%pB' as input to a link\n"), + abfd); if (bfd_input_just_syms (abfd)) continue; diff --git a/ld/lexsup.c b/ld/lexsup.c index a79bec0b45..017fecdaa8 100644 --- a/ld/lexsup.c +++ b/ld/lexsup.c @@ -2022,6 +2022,8 @@ elf_static_list_options (FILE *file) -z noexecstack Mark executable as not requiring executable stack\n")); fprintf (file, _("\ -z globalaudit Mark executable requiring global auditing\n")); + fprintf (file, _("\ + -z allowexecAllow executable files as inputs to the link\n")); } static void ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
