Re: [PATCH] efi: zboot: Ensure zboot PIC

[Pingfan Liu <kernelfans@gmail.com>]

On Tue, Mar 28, 2023 at 5:37 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Tue, 28 Mar 2023 at 11:32, Pingfan Liu <kernelfans@gmail.com> wrote:
> >
> > On Tue, Mar 28, 2023 at 3:58 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > >
> > > 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.
> > >
> >
> > Oh, I got the code piece now.  Thank you very much for pointing this
> > out. And only if R_AARCH64_ABS64 is unavoidable, there is no need to
> > ask the code to fix the relocation by itself.
> >
> > But one more question, there are many other "S+A" types of relocation,
> > let's say R_AARCH64_ABS32 or R_AARCH64_LDST64_ABS_LO12_NC. It is also
> > sensitive to the delta between loading and linking. Should all of them
> > be excluded by the Makefile?
> >
>
> None of those can be used to relocate absolute addresses, so these are
> not the ones we should care about.
>
> There are the ones related to the GOT, which could result in GOT
> entries in the final executable with R_AARCH64_RELATIVE relocations.
> However, we use 'hidden' visibility for all codegen related to the EFI
> stub, so the compiler knows all symbol references can be resolved at
> link time. This means that under -fpic or -fpie, it will always use
> relative references.
>

Appreciate for the elaboration. I got the whole story now.

Thanks,

    Pingfan

>
> > > > > > 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?
> >
> > Oops. The whole file should be arch dependent. In those cases, they
> > should be a single jump instruction.
> >
> > Appreciate for your help.
> >
> > Thanks,
> >
> >     Pingfan