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@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.