[U-Boot] [PATCH] ARM: HYP/non-sec: Propagate stack pointer to hyp mode

[Ian Campbell]

On Mon, 2014-01-06 at 10:47 +0000, Marc Zyngier wrote:
> Hi Ian,
> 
> On Sun, Dec 29 2013 at 07:07:56 PM, Ian Campbell <ijc at hellion.org.uk> wrote:
> > Some users of the u-boot API (specifically grub) use the initial SP as a hint
> > regarding where to look for the u-boot API signature.
> 
> That looks really fragile...

No kidding, but it does appear to be The Way (i.e.
u-boot.git/examples/api does it too).

TBH my impression of the API stuff is that it is a prototype which got
out of hand and became a real thing without some of the stuff which
needed doing properly getting redone. That said, I'm not offering to fix
it so I suppose I shouldn't throw stones.

> 
> > Signed-off-by: Ian Campbell <ijc at hellion.org.uk>
> > Cc: Marc Zyngier <marc.zyngier at arm.com>
> > ---
> > This applies on top of Marc's "ARMv7: add PSCI support to u-boot" and allows me
> > to chainload grub on a cubieboard2. (I don't think that has been applied
> > anywhere yet?)
> 
> Not yet, I'm still tinkering with it. See the current state at:
> git://git.kernel.org/pub/scm/linux/kernel/git/maz/u-boot.git wip/psci

Thanks for the pointer.

> > +
> > +	mrseq 	r4, sp_svc			@ Propagate SP to HYP mode
> > +	msreq	sp_hyp, r4			@ it serves as a "hint" to
> > +						@ find the u-boot API root.
> 
> So how does it work? Grub knows the range in which to find the
> signature? And then what?

It scrobbles over the region either side of this hint looking for the
signature and a valid checksum. Or as u-boot.git/api/README says:
  - consumer application will recognize the API is available by searching
    a specified (assumed by convention) range of address space for the
    signature

(where the "convention" is "around about sp on entry")

Easiest place to look is u-boot.git/examples/api/glue.c api_search_sig
and valid_sig.

On the grub side the code is grub.git/grub-core/kern/uboot/uboot.c in
grub_uboot_api_init (although it doesn't seem to check the checksum).

There isn't actually any special handling of sp on call into the guest
kernel which I can find though. It appears to rely on u-boot's malloc
placing "struct api_signature *sig" somewhere near the sp, either this
relies implicitly on the specifics of the memory layout and/or the
malloc allocator's behaviour or it is doing something too clever for me
to spot.

> Not saying this patch is wrong (it seems to solve a real problem), but
> I'd like to understand it a bit more.

There be dragons...