From: Mark Rutland <mark.rutland@arm.com>
To: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, cai@redhat.com,
catalin.marinas@arm.com, elver@google.com, james.morse@arm.com
Subject: Re: [PATCHv3] arm64: initialize per-cpu offsets earlier
Date: Thu, 4 Mar 2021 15:01:51 +0000 [thread overview]
Message-ID: <20210304150151.GD54534@C02TD0UTHF1T.local> (raw)
In-Reply-To: <20210304133023.GA21229@willie-the-truck>
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.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2021-03-04 15:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-02 11:53 [PATCHv3] arm64: initialize per-cpu offsets earlier Mark Rutland
2021-03-04 12:45 ` Will Deacon
2021-03-04 13:08 ` Mark Rutland
2021-03-04 13:30 ` Will Deacon
2021-03-04 15:01 ` Mark Rutland [this message]
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=20210304150151.GD54534@C02TD0UTHF1T.local \
--to=mark.rutland@arm.com \
--cc=cai@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=elver@google.com \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=will@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.