Re: arm: Launching EFI-enabled arm32 Linux

[Adam Lackorzynski <adam@l4re.org>]

Hi Andre,

On Mon Sep 06, 2021 at 16:34:03 +0100, Andre Przywara wrote:
> On Sat, 4 Sep 2021 21:26:45 +0200
> Adam Lackorzynski <adam@l4re.org> wrote:
> 
> Hi Adam,
> 
> > while trying to launch an EFI-enabled arm32 Linux binary (zImage) I
> > noticed I get an undefined instruction exception on the first
> > instruction. Now this is a bit special because Linux uses a nop
> > instruction there that also is a PE file signature ('MZ') such that the
> > CPU runs over it and the file is still recognized as a PE binary. Linux
> > uses 0x13105a4d (tstne r0, #0x4d000) as the instruction (see also
> > arch/arm/boot/compressed/head.S and efi-header.S in Linux).
> > However, QEMU's instruction decoder will only recognize TST with bits
> > 12-15 being 0, which this instruction is not fullfilling, and thus the
> > undef exception. I guess other CPU implementations will allow this
> > encoding. So while investigating I was doing the following to make Linux
> > proceed. I also believe this was working in a previous version of QEMU.
> > 
> > diff --git a/target/arm/a32.decode b/target/arm/a32.decode
> > index fcd8cd4f7d..222553750e 100644
> > --- a/target/arm/a32.decode
> > +++ b/target/arm/a32.decode
> > @@ -127,7 +127,7 @@ ADD_rri          .... 001 0100 . .... .... ............       @s_rri_rot
> >  ADC_rri          .... 001 0101 . .... .... ............       @s_rri_rot
> >  SBC_rri          .... 001 0110 . .... .... ............       @s_rri_rot
> >  RSC_rri          .... 001 0111 . .... .... ............       @s_rri_rot
> > -TST_xri          .... 001 1000 1 .... 0000 ............       @S_xri_rot
> > +TST_xri          .... 001 1000 1 .... ---- ............       @S_xri_rot
> >  TEQ_xri          .... 001 1001 1 .... 0000 ............       @S_xri_rot
> >  CMP_xri          .... 001 1010 1 .... 0000 ............       @S_xri_rot
> >  CMN_xri          .... 001 1011 1 .... 0000 ............       @S_xri_rot
> > 
> > 
> > Any thoughts on this?
> 
> thanks for the report, I was looking at this and have a kernel patch
> to fix this properly as Peter suggested. And while I agree on the
> problem, I was struggling to reproduce this in reality: both with
> -kernel and when booting through U-Boot the "Z" bit is set, which lets
> QEMU not even bother about the rest of the encoding - the condition
> flags don't match, so it proceeds. If I change the __nop to use "tsteq",
> I see it hanging due to the missing exception handler, but not with
> "tstne".
> So can you say how you spotted this issue? This would be needed as a
> justification for patching the guts of the ARM Linux kernel port.

Good point with the condition flags. I'm doing this with our own vmm
where I'm loading the binary directly as the payload (as mandated by the
header), and where psr is set to a defined value with all flags cleared.
If I set the Z bit than it also works (of course).
Looking a bit around in QEMU as well as u-boot I it looks like this is
rather by luck how flags are set.

Thanks for doing the Linux patch, I'll scrap mine, and also thanks to
Peter for the idea!


Adam