From: Mark Rutland <mark.rutland@arm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Maria Yu <quic_aiquny@quicinc.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel@quicinc.com,
linux-arm-msm@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH] arm64: module: PLT allowed even !RANDOM_BASE
Date: Mon, 23 Oct 2023 10:02:37 +0100 [thread overview]
Message-ID: <ZTY2rdkY5FfTBUVL@FVFF77S0Q05N> (raw)
In-Reply-To: <56c2d30b-2f25-4613-aab1-00fccbd2fa05@app.fastmail.com>
On Mon, Oct 23, 2023 at 10:08:33AM +0200, Arnd Bergmann wrote:
> On Mon, Oct 23, 2023, at 09:57, Maria Yu wrote:
> > Module PLT feature can be enabled even when RANDOM_BASE is disabled.
> > Break BLT entry counts of relocation types will make module plt entry
> > allocation fail and finally exec format error for even correct and plt
> > allocation available modules.
Has an actual problem been seen in practice, or was this found by looking at
the code?
> >
> > Signed-off-by: Maria Yu <quic_aiquny@quicinc.com>
>
> Adding Ard Biesheuvel to Cc, as he added the check in commit
> a257e02579e42 ("arm64/kernel: don't ban ADRP to work around
> Cortex-A53 erratum #843419")
I think that the actual mistake is in commit:
3e35d303ab7d22c4 ("arm64: module: rework module VA range selection")
Prior to that commit, when CONFIG_RANDOMIZE_BASE=n all modules and code had to
be within 128M of each other, and so there were no PLTs necessary for B/BL.
After that commit we can have a 2G module range regardless of
CONFIG_RANDOMIZE_BASE, and PLTs may be necessary for B/BL.
We should have removed the check for !CONFIG_RANDOMIZE_BASE as part of that.
> > arch/arm64/kernel/module-plts.c | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/module-plts.c
> > b/arch/arm64/kernel/module-plts.c
> > index bd69a4e7cd60..21a67d52d7a0 100644
> > --- a/arch/arm64/kernel/module-plts.c
> > +++ b/arch/arm64/kernel/module-plts.c
> > @@ -167,9 +167,6 @@ static unsigned int count_plts(Elf64_Sym *syms,
> > Elf64_Rela *rela, int num,
> > switch (ELF64_R_TYPE(rela[i].r_info)) {
> > case R_AARCH64_JUMP26:
> > case R_AARCH64_CALL26:
> > - if (!IS_ENABLED(CONFIG_RANDOMIZE_BASE))
> > - break;
> > -
> > /*
> > * We only have to consider branch targets that resolve
> > * to symbols that are defined in a different section.
>
> I see there are two such checks (in partition_branch_plt_relas()
> and in count_plts()), can you explain in more detail how you
> concluded that one of them is correct but the other one is not?
I believe that the one in partition_branch_plt_relas() needs to go too; that's
just a minor optimization for the case where there shouldn't be any PLTs for
B/BL, and it no longer holds after the module VA range rework.
That was introduced in commit:
d4e0340919fb9190 ("arm64/module: Optimize module load time by optimizing PLT counting")
Thanks,
Mark.
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Maria Yu <quic_aiquny@quicinc.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel@quicinc.com,
linux-arm-msm@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH] arm64: module: PLT allowed even !RANDOM_BASE
Date: Mon, 23 Oct 2023 10:02:37 +0100 [thread overview]
Message-ID: <ZTY2rdkY5FfTBUVL@FVFF77S0Q05N> (raw)
In-Reply-To: <56c2d30b-2f25-4613-aab1-00fccbd2fa05@app.fastmail.com>
On Mon, Oct 23, 2023 at 10:08:33AM +0200, Arnd Bergmann wrote:
> On Mon, Oct 23, 2023, at 09:57, Maria Yu wrote:
> > Module PLT feature can be enabled even when RANDOM_BASE is disabled.
> > Break BLT entry counts of relocation types will make module plt entry
> > allocation fail and finally exec format error for even correct and plt
> > allocation available modules.
Has an actual problem been seen in practice, or was this found by looking at
the code?
> >
> > Signed-off-by: Maria Yu <quic_aiquny@quicinc.com>
>
> Adding Ard Biesheuvel to Cc, as he added the check in commit
> a257e02579e42 ("arm64/kernel: don't ban ADRP to work around
> Cortex-A53 erratum #843419")
I think that the actual mistake is in commit:
3e35d303ab7d22c4 ("arm64: module: rework module VA range selection")
Prior to that commit, when CONFIG_RANDOMIZE_BASE=n all modules and code had to
be within 128M of each other, and so there were no PLTs necessary for B/BL.
After that commit we can have a 2G module range regardless of
CONFIG_RANDOMIZE_BASE, and PLTs may be necessary for B/BL.
We should have removed the check for !CONFIG_RANDOMIZE_BASE as part of that.
> > arch/arm64/kernel/module-plts.c | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/module-plts.c
> > b/arch/arm64/kernel/module-plts.c
> > index bd69a4e7cd60..21a67d52d7a0 100644
> > --- a/arch/arm64/kernel/module-plts.c
> > +++ b/arch/arm64/kernel/module-plts.c
> > @@ -167,9 +167,6 @@ static unsigned int count_plts(Elf64_Sym *syms,
> > Elf64_Rela *rela, int num,
> > switch (ELF64_R_TYPE(rela[i].r_info)) {
> > case R_AARCH64_JUMP26:
> > case R_AARCH64_CALL26:
> > - if (!IS_ENABLED(CONFIG_RANDOMIZE_BASE))
> > - break;
> > -
> > /*
> > * We only have to consider branch targets that resolve
> > * to symbols that are defined in a different section.
>
> I see there are two such checks (in partition_branch_plt_relas()
> and in count_plts()), can you explain in more detail how you
> concluded that one of them is correct but the other one is not?
I believe that the one in partition_branch_plt_relas() needs to go too; that's
just a minor optimization for the case where there shouldn't be any PLTs for
B/BL, and it no longer holds after the module VA range rework.
That was introduced in commit:
d4e0340919fb9190 ("arm64/module: Optimize module load time by optimizing PLT counting")
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-10-23 9:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-23 7:57 [PATCH] arm64: module: PLT allowed even !RANDOM_BASE Maria Yu
2023-10-23 7:57 ` Maria Yu
2023-10-23 8:08 ` Arnd Bergmann
2023-10-23 8:08 ` Arnd Bergmann
2023-10-23 9:02 ` Mark Rutland [this message]
2023-10-23 9:02 ` Mark Rutland
2023-10-23 9:49 ` Aiqun(Maria) Yu
2023-10-23 9:49 ` Aiqun(Maria) Yu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZTY2rdkY5FfTBUVL@FVFF77S0Q05N \
--to=mark.rutland@arm.com \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=kernel@quicinc.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_aiquny@quicinc.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.