From: Will Deacon <will@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Szabolcs Nagy <szabolcs.nagy@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: bti: Document behaviour for dynamically linked binaries
Date: Wed, 25 Mar 2020 08:07:01 +0000 [thread overview]
Message-ID: <20200325080700.GA30293@willie-the-truck> (raw)
In-Reply-To: <20200323170119.12263-1-broonie@kernel.org>
On Mon, Mar 23, 2020 at 05:01:19PM +0000, Mark Brown wrote:
> For dynamically linked binaries the interpreter is responsible for setting
> PROT_BTI on everything except itself. The dynamic linker needs to be aware
> of PROT_BTI, for example in order to avoid dropping that when marking
> executable pages read only after doing relocations, and doing everything
> in userspace ensures that we don't get any issues due to divergences in
> behaviour between the kernel and dynamic linker within a single executable.
> Add a comment indicating that this is intentional to the code to help
> people trying to understand what's going on.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> arch/arm64/kernel/process.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index 24af13d7bde6..9b668565dd10 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -674,6 +674,11 @@ asmlinkage void __sched arm64_preempt_schedule_irq(void)
> int arch_elf_adjust_prot(int prot, const struct arch_elf_state *state,
> bool has_interp, bool is_interp)
> {
> + /*
> + * For dynamicly linked executables the interpreter is
dynamicly => dynamically
> + * responsible for setting PROT_BTI on everything except
> + * itself.
> + */
> if (is_interp != has_interp)
> return prot;
Catalin: With the typo fixed, it's probably worth sticking this on
for-next/bti so we don't lose it, but I don't think this is really 5.7
material until the tools folks are happy with the ABI. It's pretty
frustrating, but committing to something broken would be far worse and
it's better to get these issues resolved *now* before anything hits
mainline.
Will
_______________________________________________
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:[~2020-03-25 8:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-23 17:01 [PATCH] arm64: bti: Document behaviour for dynamically linked binaries Mark Brown
2020-03-25 8:07 ` Will Deacon [this message]
2020-03-25 9:50 ` Catalin Marinas
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=20200325080700.GA30293@willie-the-truck \
--to=will@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=szabolcs.nagy@arm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox