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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 22 Jul 2007 01:59:40 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	David Miller <davem@...emloft.net>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: "build-id" changes break sparc64

> (This is in reference to commit 18991197b4b588255ccabf472ebc84db7b66a19c)
> 
> When actually used, the build-id linker option causes problems for the
> sparc64 kernel in two ways:
> 
> 1) When building modules we get tons of warnings from the linker
>    such as:
> 
>   LD [M]  drivers/scsi/sr_mod.o
> ld: warning: Cannot create .note.gnu.build-id section, --build-id ignored.

This is probably a bug in the new ld code (which is still quite unreleased,
even if bleeding-edge distro builds are using it already).  Please work
with me (off the kernel list) to figure that out.

>    build-id puts a second PT_LOAD into the kernel image (albeit a tiny
>    one) and as a result it cannot be booted

This probably just requires a linker script tweak to use the NOTES macro.
Maybe:

--- a/arch/sparc64/kernel/vmlinux.lds.S
+++ b/arch/sparc64/kernel/vmlinux.lds.S
@@ -19,6 +19,7 @@ SECTIONS
     SCHED_TEXT
     LOCK_TEXT
     KPROBES_TEXT
+    NOTES
     *(.gnu.warning)
   } =0
   _etext = .;

I did not change every platform's script where I wasn't sure if a change
was required or what it needed to be.  It may be that every platform that
doesn't use the NOTES macro in its vmlinux.lds.S really needs to.  (Place
it anywhere you like that is appropriate for a few dozen read-only bytes
that will rarely be read.)

> Whilst #1 could be some kind of binutils bug and the warning
> is harmless, #2 is an outright show-stopper for sparc32 and
> sparc64 and to be honest I would not be surprised if the
> boot loader on some other platforms have this limitation too.

There's no expectation of changing anything about the layout.
Just a linker script tweak might be required so the tiny new
section falls somewhere proper in the existing layout.

> Alternatively, if you think build-id is so valuable, impress me with
> your binutils ninja skills and show me how to perhaps do some objcopy
> tricks wherein I could dike out the PT_LOAD segment build-id generates
> for the "image" target et al.  in the arch/sparc{,64}/boot/Makefile's
> rules.

I have indeed performed some odd feats in this area in the past, but in
this case there should be not any need for anything of the sort.

I would prefer not to let the feature lag while every platform gets around
to adding a Makefile line.  It really should be universal and simple to
deal with.  The ld feature is still so bleeding-edge that there should be
ample time to iron out kinks before anyone could be bit by it who wasn't
really asking for it.


Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ