[U-Boot] [PATCH 2/2] arm64: booti: allow to place kernel image anywhere in physical memory

[Tom Rini]

On Tue, Mar 07, 2017 at 11:43:52AM +0000, Mark Rutland wrote:
> On Tue, Feb 28, 2017 at 12:15:09PM -0500, Tom Rini wrote:
> > On Wed, Mar 01, 2017 at 02:03:58AM +0900, Masahiro Yamada wrote:
> > > 2017-02-27 7:41 GMT+09:00 Tom Rini <trini at konsulko.com>:
> > > > On Thu, Feb 23, 2017 at 10:31:17AM -0500, Tom Rini wrote:
> 
> > > > c) I'm not convinced your math above is correct.  images->ep is where we
> > > > were put in memory.  This is what we should make sure is 2MiB aligned,
> > > > and then add to it the text_offset.  And some quick testing with
> > > > CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET enabled Images :)
> > > 
> > > My intention is
> > > 
> > >   images->ep  =  (2MiB aligned base)  + text_offset
> > > 
> > > If this equation is met, the image is already placed at the bootable position.
> > > We can skip the relocation.
> > > 
> > > Theoretically, we can not know the value of text_offset in advance
> > > (especially for CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET).
> > > However, in practice, we know text_offset is 0x80000.
> 
> Per the arm64 Image header, no particular value  of text_offset should
> be assumed. Please do not assume a particular value
> 
> It has always been the intent that bootloaders should read this, though
> this evidently wasn't very clear (and the bootwrapper set a bad
> example). I tried to clear this up with documentation updates (and the
> addition of ARM64_RANDOMIZE_TEXT_OFFSET).
> 
> > > If we put the image at 2MiB aligned base, the relocation would
> > > always happen.
> > 
> > Correct.  But I honestly don't know if non-randomized text offset is the
> > common case people will optimize for or randomized for added security will be
> > the more common case.  
> 
> FWIW, the randomized text_offset is a bootloader debugging/testing
> feature, and there's no security aspect to it.
> 
> It was added [1] as an additional to hint to bootloader authors that
> they must respect the text_offset field.

Right, and we do this today.  But since this doubles as a kind of cheap
KASLR I would also expect to see it used, even if not intended, in this
way.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170307/a1e1099b/attachment.sig>