public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/4] arm64: Enable TEXT_OFFSET fuzzing
Date: Fri, 16 May 2014 17:55:48 +0100	[thread overview]
Message-ID: <20140516165548.GA14766@leverpostej> (raw)
In-Reply-To: <20140516140606.GH5624@arm.com>

On Fri, May 16, 2014 at 03:06:07PM +0100, Catalin Marinas wrote:
> On Fri, May 16, 2014 at 10:50:39AM +0100, Mark Rutland wrote:
> > --- a/arch/arm64/Kconfig.debug
> > +++ b/arch/arm64/Kconfig.debug
> > @@ -37,4 +37,35 @@ config PID_IN_CONTEXTIDR
> >  	  instructions during context switch. Say Y here only if you are
> >  	  planning to use hardware trace tools with this kernel.
> >  
> > +config ARM64_RANDOMIZE_TEXT_OFFSET
> > +	bool "Randomize TEXT_OFFSET at build time (EXPERIMENTAL)"
> > +	default N
> 
> (nitpick: no need for default n)

Thanks for pointing that out, I'll remove it :)

> I think that's good for testing. It would have been nice to be able to
> set some limits for the random offset but I can't figure out an easy way
> to do this via Kconfig (maybe with additional options).

There are hard-coded limits implicit in the randomization -- between 0B
and 2MB in 16B increments:

TEXT_OFFSET := $(shell awk 'BEGIN {srand(); printf "0x%05x\n", and(int(0xfffff * rand()), 0xffff0)}')

The 16B increment is required due to some code in head.S (__turn_mmu_on)
requiring a minimum 16B alignment for the object.

The 2MB maximum comes from the fact we rely on the start of memory being
2MB aligned. I'm not sure there's a compelling reason to limit the
randomization if enabled at all -- either you can handle it or you
can't. Are we ever likely to want an offset larger than the memory
alignment?

> > +config ARM64_TEXT_OFFSET
> > +	hex "Required image load offset"
> > +	depends on !ARM64_RANDOMIZE_TEXT_OFFSET
> > +	default "0x0000000000080000"
> 
> I don't think we should include this. It encourages people to set
> specific offsets for their SoCs.

Sure, I was worried about potential abuse also (hence the warning in the
help text). I'll drop this portion.

Cheers,
Mark.

  reply	other threads:[~2014-05-16 16:55 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-16  9:50 [PATCH 0/4] arm64: simplify restrictions on bootloaders Mark Rutland
2014-05-16  9:50 ` [PATCH 1/4] arm64: head.S: remove unnecessary function alignment Mark Rutland
2014-05-16 13:04   ` Christopher Covington
2014-05-20 16:20   ` Laura Abbott
2014-05-16  9:50 ` [PATCH 2/4] arm64: place initial page tables above the kernel Mark Rutland
2014-05-20 16:21   ` Laura Abbott
2014-05-16  9:50 ` [PATCH 3/4] arm64: export effective Image size to bootloaders Mark Rutland
2014-05-20 14:12   ` Tom Rini
2014-05-20 16:22   ` Laura Abbott
2014-06-16 20:27   ` Geoff Levand
2014-06-18 16:49     ` Mark Rutland
2014-06-18 18:27       ` Rob Herring
2014-06-18 18:41       ` Geoff Levand
2014-06-19 10:25         ` Mark Rutland
2014-06-19 18:07           ` Geoff Levand
2014-06-20 10:17             ` Mark Rutland
2014-06-18 18:56       ` Kevin Hilman
2014-06-18 23:03       ` [PATCH] arm64: Add byte order to image header Geoff Levand
2014-06-18 23:07         ` [PATCH] arm64: Add new file asm/image.h Geoff Levand
2014-05-16  9:50 ` [PATCH 4/4] arm64: Enable TEXT_OFFSET fuzzing Mark Rutland
2014-05-16 14:06   ` Catalin Marinas
2014-05-16 16:55     ` Mark Rutland [this message]
2014-05-20 14:11       ` Tom Rini
2014-05-20 16:08         ` Mark Rutland
2014-05-21 10:18           ` Mark Rutland
2014-05-20 11:31 ` [PATCH 0/4] arm64: simplify restrictions on bootloaders Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140516165548.GA14766@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox