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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 17 May 2020 12:44:29 -0700
From:   Fangrui Song <>
To:     Dmitry Golovin <>
Cc:     Borislav Petkov <>,
        Thomas Gleixner <>,
        Ingo Molnar <>,
        "" <>,
        "H. Peter Anvin" <>,
        Nick Desaulniers <>,
        Ard Biesheuvel <>,
        Masahiro Yamada <>,
        Daniel Kiper <>,
        "" <>
Subject: Re: [PATCH] x86/boot: allow a relocatable kernel to be linked with

On 2020-05-16, Dmitry Golovin wrote:
>15.05.2020, 21:50, "Borislav Petkov" <>:
>> I need more info here about which segment is read-only?
>> Is this something LLD does by default or what's happening?
>Probably should have quoted the original error message:
>    ld.lld: error: can't create dynamic relocation R_386_32 against
>    symbol: _bss in readonly segment; recompile object files with -fPIC
>    or pass '-Wl,-z,notext' to allow text relocations in the output

Do we know where do these R_386_32 come from?

When linking in -shared mode, the linker assumes the image is a shared
object and has undetermined image base at runtime. An absolute
relocation needs a text relocation (a relocation against a readonly

When neither -z notext nor -z text is specified, GNU ld is in an
indefinite state where it will enable text relocations (DT_TEXTREL
DF_TEXTREL) on demand. It is not considered a good practice for
userspace applications to do this.

Of course the kernel is different....... I know little about the kernel,
but if there is a way to make the sections containing R_386_32
relocations writable (SHF_WRITE), that will be a better solution to me.
In LLD, -z notext is like making every section SHF_WRITE.

>> IOW, don't be afraid to be more verbose in the commit message. :)
>Tried both BFD and LLD for linking to understand the difference more and
>rewrite the commit message, and came to the conclusion that the patch is
>wrong. I will submit v2 when I figure out the correct solution.
>You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to
>To view this discussion on the web visit

Powered by blists - more mailing lists