All of lore.kernel.org
 help / color / mirror / Atom feed
From: ard.biesheuvel@linaro.org (Ard Biesheuvel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
Date: Thu, 25 Feb 2016 17:50:17 +0100	[thread overview]
Message-ID: <CAKv+Gu_dXEQ1U2XY2=xX7R8MoPB0jKM7Vh3zgZB9tBuMfQYuGg@mail.gmail.com> (raw)
In-Reply-To: <CAKv+Gu8GYhPeXvgpAoHxYTYfqEHLqqLHVU9U6o3nvxew8dGo6A@mail.gmail.com>

On 25 February 2016 at 17:49, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 25 February 2016 at 17:46, Will Deacon <will.deacon@arm.com> wrote:
>> On Thu, Feb 25, 2016 at 05:43:35PM +0100, Ard Biesheuvel wrote:
>>> On 25 February 2016 at 17:42, Will Deacon <will.deacon@arm.com> wrote:
>>> > On Thu, Feb 25, 2016 at 05:33:25PM +0100, Ard Biesheuvel wrote:
>>> >> AFAIK, gcc never uses x18 (the platform register) so we may be able to
>>> >> use that instead. We'd need confirmation from the toolchain guys,
>>> >> though ...
>>> >
>>> > In fact, a better thing to do is probably for the atomic code to
>>> > save/restore those register explicitly and then remove them from the
>>> > cflags above.
>>> >
>>> > I'll try hacking something together...
>>> >
>>>
>>> That would be more correct, indeed. Also, the PLT can only use br
>>> <reg> so it will always enter the callee with the preserved value
>>> stacked, and so the callee needs to be modified in any case.
>>
>> Wait -- why does the callee need to be modified here? It has no idea
>> about whether or not it was invoked via a PLT.
>>
>
> No, it doesn't, and that is exactly the problem: the PLT must end in a
> br <reg> instruction because that is the only branch instruction with
> unlimited range. That means you will always enter the callee with its
> address in some register rather than the value that should have been
> preserved. I don't see a way to manage that from the callee
>

*caller! dammit

>> Also, can I rely on the PLT not clobbering the condition code?
>>
>
> For my particular implementation, yes.

  reply	other threads:[~2016-02-25 16:50 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-01 13:09 [PATCH v5sub2 0/8] arm64: implement virtual KASLR Ard Biesheuvel
2016-02-01 13:09 ` [PATCH v5sub2 1/8] arm64: add support for module PLTs Ard Biesheuvel
2016-02-04 15:13   ` Catalin Marinas
2016-02-04 15:31     ` Ard Biesheuvel
2016-02-05 15:42       ` Catalin Marinas
2016-02-05 15:53         ` Ard Biesheuvel
2016-02-05 16:00           ` Catalin Marinas
2016-02-05 16:20             ` Ard Biesheuvel
2016-02-05 16:46               ` Catalin Marinas
2016-02-05 16:54                 ` Ard Biesheuvel
2016-02-05 17:21                   ` Catalin Marinas
2016-02-05 20:39                   ` Kees Cook
2016-02-08 10:12                     ` [PATCH] arm64: allow the module region to be randomized independently Ard Biesheuvel
2016-02-08 18:13                       ` Catalin Marinas
2016-02-08 18:29                         ` Ard Biesheuvel
2016-02-09 10:03                         ` Ard Biesheuvel
2016-02-09 10:45                           ` Catalin Marinas
2016-02-25 16:07   ` [PATCH v5sub2 1/8] arm64: add support for module PLTs Will Deacon
2016-02-25 16:12     ` Ard Biesheuvel
2016-02-25 16:13       ` Ard Biesheuvel
2016-02-25 16:26       ` Will Deacon
2016-02-25 16:33         ` Ard Biesheuvel
2016-02-25 16:42           ` Will Deacon
2016-02-25 16:43             ` Ard Biesheuvel
2016-02-25 16:46               ` Will Deacon
2016-02-25 16:49                 ` Ard Biesheuvel
2016-02-25 16:50                   ` Ard Biesheuvel [this message]
2016-02-25 16:56                     ` Will Deacon
2016-02-25 17:31                       ` Ard Biesheuvel
2016-02-25 18:29                         ` Will Deacon
2016-02-01 13:09 ` [PATCH v5sub2 2/8] arm64: avoid R_AARCH64_ABS64 relocations for Image header fields Ard Biesheuvel
2016-02-01 13:09 ` [PATCH v5sub2 3/8] arm64: avoid dynamic relocations in early boot code Ard Biesheuvel
2016-02-01 13:09 ` [PATCH v5sub2 4/8] arm64: make asm/elf.h available to asm files Ard Biesheuvel
2016-02-01 13:09 ` [PATCH v5sub2 5/8] scripts/sortextable: add support for ET_DYN binaries Ard Biesheuvel
2016-02-01 13:09 ` [PATCH v5sub2 6/8] arm64: add support for building vmlinux as a relocatable PIE binary Ard Biesheuvel
2016-02-01 13:09 ` [PATCH v5sub2 7/8] arm64: add support for kernel ASLR Ard Biesheuvel
2016-02-01 13:09 ` [PATCH v5sub2 8/8] arm64: kaslr: randomize the linear region Ard Biesheuvel
2016-02-01 13:35 ` [PATCH v5sub2 0/8] arm64: implement virtual KASLR Ard Biesheuvel
2016-02-05 17:32   ` Catalin Marinas
2016-02-05 17:38     ` Ard Biesheuvel
2016-02-05 17:46       ` Catalin Marinas
2016-02-05 20:42       ` Kees Cook
2016-02-08 12:14         ` Catalin Marinas
2016-02-08 14:30           ` Ard Biesheuvel
2016-02-08 16:19             ` Catalin Marinas
2016-02-08 16:20               ` Ard Biesheuvel
2016-02-08 16:46                 ` 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='CAKv+Gu_dXEQ1U2XY2=xX7R8MoPB0jKM7Vh3zgZB9tBuMfQYuGg@mail.gmail.com' \
    --to=ard.biesheuvel@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.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.