[PATCHv3] arm64: initialize per-cpu offsets earlier

[Will Deacon]

On Thu, Mar 04, 2021 at 01:08:35PM +0000, Mark Rutland wrote:
> On Thu, Mar 04, 2021 at 12:45:11PM +0000, Will Deacon wrote:
> > On Tue, Mar 02, 2021 at 11:53:35AM +0000, Mark Rutland wrote:
> > > The current initialization of the per-cpu offset register is difficult
> > > to follow and this initialization is not always early enough for
> > > upcoming instrumentation with KCSAN, where the instrumentation callbacks
> > > use the per-cpu offset.
> > > 
> > > To make it possible to support KCSAN, and to simplify reasoning about
> > > early bringup code, let's initialize the per-cpu offset earlier, before
> > > we run any C code that may consume it. To do so, this patch adds a new
> > > init_this_cpu_offset() helper that's called before the usual
> > > primary/secondary start functions. For consistency, this is also used to
> > > re-initialize the per-cpu offset after the runtime per-cpu areas have
> > > been allocated (which can change CPU0's offset).
> > 
> > Is this still early enough now that we have the idreg overrides on the
> > command-line, which are parsed from C code?
> 
> Hmm... no, it's not, given the override code can be instrumented and
> calls potentially instrumented library code too, so we can't just
> prevent kcsan instrumentation of the file.
> 
> I'll go give this a more thorough audit, since (while I had previously
> convinced myself otherwise), the early KASLR bits look potentially
> problematic too.

Ideally, we'd be able to use KCSAN anywhere we can use KASAN and then not
have to worry about the two independently.

Will