Re: [RFC PATCH] arm64: fix the missing ktpi= cmdline check in arm64_kernel_unmapped_at_el0()

[Mark Brown]

On Tue, Mar 17, 2020 at 03:18:14PM +0000, Will Deacon wrote:
> On Tue, Mar 17, 2020 at 01:57:19PM +0000, Mark Brown wrote:
> > On Tue, Mar 17, 2020 at 12:43:24PM +0000, Will Deacon wrote:
> > > On Tue, Mar 17, 2020 at 12:10:51PM +0000, Mark Rutland wrote:
> > > > On Tue, Mar 17, 2020 at 07:47:08PM +0800, Hongbo Yao wrote:

> > > > > -	return arm64_use_ng_mappings;
> > > > > +	return arm64_use_ng_mappings &&
> > > > > +		cpus_have_const_cap(ARM64_UNMAP_KERNEL_AT_EL0);

> > > This probably isn't the right fix, since this will mean that early mappings
> > > will be global and we'll have to go through the painful page-table rewrite
> > > logic when the cap gets enabled for KASLR-enabled kernels.

> > Aren't we looking for a rewrite from non-global to global here (disable
> > KPTI where we would otherwise have it), which we don't currently have
> > code for?

> What I mean is that cpus_have_const_cap() will be false initially, so we'll
> put down global mappings early on because PTE_MAYBE_NG will be 0, which
> means that we'll have to invoke the rewriting code if we then realise we
> want non-global mappings after the caps are finalised.

Ah, I see - a different case to the one originally reported but also an
issue.

> > That is probably a good idea but I think that runs too late to affect
> > the early mappings, they're done based on kaslr_requires_kpti() well
> > before we start secondaries.  My first pass not having paged everything
> > back in yet is that there needs to be command line parsing in
> > kaslr_requires_kpti() but as things stand the command line isn't
> > actually ready then...

> Yeah, and I think you probably run into chicken and egg problems mapping

The whole area is just a mess.

> the thing. With the change above, it's true that /some/ mappings will
> still be nG if you pass kpti=off, but I was hoping that didn't really matter
> :)

> What was the behaviour prior to your patch? If it used to work without
> any nG mappings, then I suppose we should try to restore that behaviour.

I'd need to go back and retest to confirm but it looks like always had
the issue that we'd install some nG mappings early even with KPTI
disabled on the command line so your change is just restoring the
previous behaviour and we're no worse than we were before.

Attachment: signature.asc
Description: PGP signature