linux-kernel - Re: [PATCH 7/7] modpost: detect section mismatch for R_ARM

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]

Date:   Thu, 1 Jun 2023 16:40:54 +0200
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Masahiro Yamada <masahiroy@...nel.org>
Cc:     linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        Russell King <linux@...linux.org.uk>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Nicolas Schier <nicolas@...sle.eu>
Subject: Re: [PATCH 7/7] modpost: detect section mismatch for R_ARM_REL32

On Thu, 1 Jun 2023 at 16:36, Masahiro Yamada <masahiroy@...nel.org> wrote:
>
> On Thu, Jun 1, 2023 at 9:40 PM Ard Biesheuvel <ardb@...nel.org> wrote:
> >
> > On Thu, 1 Jun 2023 at 14:10, Masahiro Yamada <masahiroy@...nel.org> wrote:
> > >
> > > For ARM, modpost fails to detect some types of section mismatches.
> > >
> > >   [test code]
> > >
> > >     .section .init.data,"aw"
> > >     bar:
> > >             .long 0
> > >
> > >     .section .data,"aw"
> > >     .globl foo
> > >     foo:
> > >             .long bar - .
> > >
> > > It is apparently a bad reference, but modpost does not report anything.
> > >
> > > The test code above produces the following relocations.
> > >
> > >   Relocation section '.rel.data' at offset 0xe8 contains 1 entry:
> > >    Offset     Info    Type            Sym.Value  Sym. Name
> > >   00000000  00000403 R_ARM_REL32       00000000   .init.data
> > >
> > > Currently, R_ARM_REL32 is just skipped.
> > >
> > > Handle it like R_ARM_ABS32.
> >
> > OK, so the reason we can handle these in the same way is because we
> > never calculate the resulting value, right? Because that value would
> > be different for these cases.
>
> Right.
>
> '- loc' is unnecessary here because modpost never calculates the
> resulting instruction.
>
> modpost wants to know the location of the referenced symbol.
> (the offset from the start of the section).
>
> For the same reason, I omitted '- loc' for
> PC-relative ones such as R_ARM_CALL, R_ARM_JUMP24, etc.
>

OK makes sense - I just wanted to double check