[PATCH v2 2/3] arm64: Bail out PIE builds early if load address is not 4K aligned

[Edgar E. Iglesias <edgar.iglesias@xilinx.com>]

On Mon, Sep 07, 2020 at 08:57:39AM -0400, Tom Rini wrote:
> On Mon, Sep 07, 2020 at 11:52:35AM +0200, Edgar E. Iglesias wrote:
> > On Fri, Sep 04, 2020 at 12:43:57PM -0600, Stephen Warren wrote:
> > > On 9/4/20 3:07 AM, Edgar E. Iglesias wrote:
> > > > From: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com>
> > > > 
> > > > PIE requires a 4K aligned load address. If this is not met, trap
> > > > the startup sequence in a WFI loop rather than running into obscure
> > > > failures.
> > > 
> > > > diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
> > > >  #if CONFIG_POSITION_INDEPENDENT
> > > > +	/* Verify that we're 4K aligned.  */
> > > 
> > > Similar to the comment on the previous patch: I believe the code that
> > > implements this check should be outside the #if check, since it's always
> > > needed.
> > 
> > But a check for non-PIE would have to be stricter, wouldn't it?
> > I.e the load address needs to exactly match the link-time address.
> > 
> > Perhaps we should add the non-PIE check in a separate patch (if at all)?
> 
> If we can catch a bad configuration at link time in the non-PIE case (as
> said in another part of this thread I believe) then we should, yes,
> thanks!

The non-PIE configuration is expected to be loaded at a specific address.
The actual load address cannot be checked at link-time (since it's up to
the user at run-time) but given the assumption of a specific load-address,
4K alignment can be enforced at link-time.

It really comes down to adding reasonable run-time checks for errors that
users may reasonably struggle with.

For PIE, checking for 4K aligment is reasonable because it's an easy
enough misstake to make (since you've got a binary that's was supposed to
handle relocation).

For non-PIE, checking for the exact address at run-time is a little bit more
border-line IMO but I guess also somewhat reasonable.

There are still plenty of cases we can't catch though (loaded at odd addreses,
non-RAM address-ranges etc etc).

Cheers,
Edgar