[PATCHv3] arm64: initialize per-cpu offsets earlier

[Mark Rutland]

On Thu, Mar 04, 2021 at 01:30:24PM +0000, Will Deacon wrote:
> 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.

Yup; I completely agree -- that's the "simplify reasoning" part of my
rationale. ;)

Mark.