linux-kernel - Re: [PATCH v2] scripts: Do not strip .rela.dyn section

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] [day] [month] [year] [list]

Message-ID: <CAK7LNATik6YPYZ5H2n9NXcG=WP3ThvCHpN=azAULmvUEMs5R3A@mail.gmail.com>
Date: Fri, 11 Apr 2025 03:31:44 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Alexandre Ghiti <alex@...ti.fr>
Cc: Alexandre Ghiti <alexghiti@...osinc.com>, Ard Biesheuvel <ardb@...nel.org>, 
	Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>, 
	Björn Töpel <bjorn@...osinc.com>, 
	Nathan Chancellor <nathan@...nel.org>, Nicolas Schier <nicolas@...sle.eu>, 
	Charlie Jenkins <charlie@...osinc.com>, linux-kernel@...r.kernel.org, 
	linux-riscv@...ts.infradead.org, linux-kbuild@...r.kernel.org
Subject: Re: [PATCH v2] scripts: Do not strip .rela.dyn section

On Mon, Apr 7, 2025 at 5:43 PM Alexandre Ghiti <alex@...ti.fr> wrote:
>
>
> On 07/04/2025 10:15, Alexandre Ghiti wrote:
> > Hi Masahiro,
> >
> > On Fri, Apr 4, 2025 at 5:25 PM Masahiro Yamada <masahiroy@...nel.org> wrote:
> >> On Fri, Apr 4, 2025 at 12:45 AM Alexandre Ghiti <alex@...ti.fr> wrote:
> >>> Hi Ard,
> >>>
> >>> On 03/04/2025 17:11, Ard Biesheuvel wrote:
> >>>> On Thu, 3 Apr 2025 at 16:42, Alexandre Ghiti <alexghiti@...osinc.com> wrote:
> >>>>> riscv uses the .rela.dyn section to relocate the kernel at runtime but
> >>>>> that section is stripped from vmlinux. That prevents kexec to
> >>>>> successfully load vmlinux since it does not contain the relocations info
> >>>>> needed.
> >>>>>
> >>>> Maybe explain that .rela.dyn contains runtime relocations, which are
> >>>> only emitted if they are actually needed - as opposed to the static
> >>>> relocations that are not emitted as SHF_ALLOC sections, and are not
> >>>> considered to be part of the runtime image in the first place.
> >>>
> >>> Ok I'll do.
> >>>
> >>>
> >>>> It
> >>>> would be nice if we could use --remove-relocations= here, which only
> >>>> removes static relocations, but unfortunately, llvm-objcopy does not
> >>>> support this.
> >>>>
> >>>> Also, I wonder if this should apply to all of .rel.dyn, .rela.dyn and
> >>>> .relr.dyn, as they all carry runtime relocations.
> >>>
> >>> Ok, I'll add them to the next version.
> >>>
> >>>
> >>>> Finally, I'd be curious to know why RISC-V relies on --emit-relocs in
> >>>> the first place? Is the relocs check really needed? If not, it would
> >>>> be a nice opportunity to get rid of Makefile.postlink entirely.
> >>>
> >>> So I had to check and it happens that this was an issue with the
> >>> toolchain, I should check if that still happens with newer ones.
> >>>
> >>> commit 559d1e45a16dcf1542e430ea3dce9ab625be98d0
> >>> Author: Alexandre Ghiti <alexghiti@...osinc.com>
> >>> Date:   Wed Mar 29 06:53:29 2023 +0200
> >>>
> >>>       riscv: Use --emit-relocs in order to move .rela.dyn in init
> >>
> >>
> >>
> >> So,
> >>
> >> Fixes: 559d1e45a16d ("riscv: Use --emit-relocs in order to move
> >> .rela.dyn in init")
> >>
> >> Is this the correct tag?
> > This is the initial culprit yes, but if we use this tag, the fix won't
> > apply. So I decided to pick Ard's patch so that this fix can be easily
> > backported to 6.14, and I'll come up with a new version for previous
> > releases. Is that ok with you?
>
>
> And I have just looked at 6.15-rc1 and noticed that the relocation
> stripping was moved to Makefile.vmlinux, so this fix won't apply to 6.14
> neither.
>
> I'll then use the initial culprit, which is Fixes: 559d1e45a16d ("riscv:
> Use --emit-relocs in order to move.rela.dyn in init").
>
> Sorry for the noise,

You do not need to worry about whether this commit can be cleanly
back-ported to the stable kernels or not.

If the fix cleanly applies, the process should be easy (and almost automatic).

If not, we can modify the patch context and submit to the stable ML.
This needs manual modification, but is still possible.


-- 
Best Regards
Masahiro Yamada