All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: Pingfan Liu <kernelfans@gmail.com>
Cc: linux-efi@vger.kernel.org, Kees Cook <keescook@chromium.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Sami Tolvanen <samitolvanen@google.com>,
	Huacai Chen <chenhuacai@kernel.org>
Subject: Re: [PATCH] efi: zboot: Ensure zboot PIC
Date: Tue, 28 Mar 2023 09:58:36 +0200	[thread overview]
Message-ID: <CAMj1kXHuc0X2ChArtcecqAma5jZNyFhjpESB6s9c4NmgzE3o9Q@mail.gmail.com> (raw)
In-Reply-To: <CAFgQCTuc7yshP8gUJ4XzRR23R5HqoQ02qkA_cvXJM9BXMXLsUw@mail.gmail.com>

On Tue, 28 Mar 2023 at 09:32, Pingfan Liu <kernelfans@gmail.com> wrote:
>
> On Mon, Mar 27, 2023 at 6:57 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Mon, 27 Mar 2023 at 11:51, Pingfan Liu <kernelfans@gmail.com> wrote:
> > >
> > > Using objcopy to reform vmlinuz.efi.elf to vmlinuz.efi will not convey
> > > any relocation information. That means vmlinuz.efi is expected to be
> > > PIC.
> > >
> > > At present, vmlinuz.efi is PIC. But it is better to adopt the same
> >
> > Why is it better?
> >
>
> I think except carefully coded with asm language, there is no
> guarantee which prevents the compiler from generating position
> dependent code.  Or is there any presumption here?
>

All object files built under drivers/firmware/efi/libstub are scanned
for absolute relocations, and if any exist, the build is aborted.

> > > solution used by the kernel to resolve the code relocation issue by
> > > itself. That is to resolve R_AARCH64_RELATIVE at the runtime.
> > >
> >
> > This breaks other architectures.
> >
>
> Oops, could it be done by:
> #if defined(_aarch64_)
> #define R_ARCH_RELATIVE R_AARCH64_RELATIVE
> #else
> #define R_ARCH_RELATIVE 0
> #endif
>
> Since any r_type equaling 0 can not be ejected into the relocation
> section, this macro will make the code dummy in essential.
>

So the assembler instructions you are using are also implemented on
RISC-V and LoongArch?

  reply	other threads:[~2023-03-28  7:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-27  9:51 [PATCH] efi: zboot: Ensure zboot PIC Pingfan Liu
2023-03-27 10:57 ` Ard Biesheuvel
2023-03-28  7:32   ` Pingfan Liu
2023-03-28  7:58     ` Ard Biesheuvel [this message]
2023-03-28  9:32       ` Pingfan Liu
2023-03-28  9:37         ` Ard Biesheuvel
2023-03-29  8:24           ` Pingfan Liu

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=CAMj1kXHuc0X2ChArtcecqAma5jZNyFhjpESB6s9c4NmgzE3o9Q@mail.gmail.com \
    --to=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=chenhuacai@kernel.org \
    --cc=keescook@chromium.org \
    --cc=kernelfans@gmail.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=samitolvanen@google.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 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.