question about RISCV EFI stub support

[Ard Biesheuvel]

On Mon, 1 Mar 2021 at 15:43, Kefeng Wang <wangkefeng.wang at huawei.com> wrote:
>
> + Palmer, sorry forget add to cc list...
>
> On 2021/2/25 10:00, Atish Patra wrote:
> > On Wed, Feb 24, 2021 at 5:29 PM Kefeng Wang <wangkefeng.wang at huawei.com> wrote:
> >>
> >> On 2021/2/25 7:35, Atish Patra wrote:
> >>> On Wed, Feb 24, 2021 at 3:14 AM Kefeng Wang <wangkefeng.wang at huawei.com> wrote:
> >>>> Hi Atish and Ard,
> >>>>
> >>>> The commit "cb7d2dd5612a RISC-V: Add PE/COFF header for EFI stub" use
> >>>> c.li to
> >>>>
> >>>> add Magic "MZ" signature for PE/COFF header, which select RISCV_ISA_C,
> >>>> but "C"
> >>>>
> >>>> to the ISA is optional,  and if "C" is not support ,  EFI boot is not
> >>>> supported.
> >>>>
> >>>> Could we use ".word MZ_MAGIC" like x86 code or some other way to support
> >>>> "MZ" signature?
> >>>>
> >>> .word won't work but .short will. With .word, you end up 0000 in the 2
> >>> bytes which can be interpreted as illegal instruction.
> >> Yes, should use ".short" in RV.
> >>> I guess your larger objective is to make the C extension optional and
> >>> not enabled by default for the Linux kernel.
> >> "C" extension is optional, and the upstream kernel has the RISCV_ISA_C which
> >>
> >> could be configurable.  and I think the EFI_STUB should not depend or
> >> select it,
> >>
> >> and maybe we only want to support RV64G in some cases,  what's your option?
> >>
> > I think RISCV_ISA_C was enabled by default just to generate a smaller
> > binary size.
> > @palmer : was there any other reason ?
>
> Any comment about the too issue,
>
> 1)  directly use .shout MZ_MAGIC to decouple EFI_STUB and RISCV_ISA_C.
>
> 2)  don't set RISCV_ISA_C  to default y
>

But doesn't that break non-EFI boot with the same image? The opcode
still needs to be executable, and have close-to-NOP semantics.