Re: [GIT PULL] x86 fixes

[Ingo Molnar <mingo@kernel.org>]

* Andy Lutomirski <luto@kernel.org> wrote:

> > Is this tree looking good to you standalone?
> 
> I think this stuff is looking okay, although I'm a bit mystified by
> the whole merge base thing.  But if the backporters and Linus like it,
> then whatever.

To explain the merge base thing: considering that v4.14 is an LTS kernel the PTI 
merge base thing is really mostly about keeping this commit count low:

  triton:~/tip> git log --no-merges --oneline v4.14..tip/WIP.x86/pti.base | wc -l
  63

Versus the closest upstream work-alike equivalent base tree, which is, roughly:

  triton:~/tip> git log --no-merges --oneline v4.14..99306dfc067e | wc -l
  1088

1088 is a lot of commits to backport, all sourced from early in the merge window - 
which would also require the identification of ~dozens of random followup fixes 
later in the merge window and the -rc process - which fixes might not even 
cherry-pick cleanly due to other interactions...

So the upstream price of the 'PTI merge base' is 9 cherry-picks, to avoid 
backporting either 1000+ commits to -stable (not workable to -stable folks, 
especially as such wide backports also tend to explode exponentially by pulling in 
random dependencies as you try to backport them further back) or the non-Git 
backporting of 100+ iffy low level x86 entry code commits to the LTS kernel (still 
a nightmare to both the -stable and us x86 maintainers).

Note that doing this also allows tip:x86/pti to remain on this almost-v4.14 base 
for a few more weeks after an upstream merge, so it can collect any eventual fixes 
and minor enhancements into a linear series of commits. This, considering the 
complexity of PTI, is good both for bisectability and for backporting.

So as long as the ~9 cherry-picks are cleanly structured and are explicitly 
marked, this is the best all around solution we could think of.

( The somewhat weird git-merge gynastics in the tree I sent to Linus are really 
  about merging specific versions of upstream that are content-equivalent with
  the cherry-picks, to avoid massive conflicts. v4.15 had various other changes to 
  the files affected by the cherry-picking. If done naively the cherry-picked tree 
  merge can generate over a dozen nasty conflicts. Doing it this way also creates 
  more confidence in the cherry-picked base tree itself: -stable folks can trust 
  it more because it will be 'obviously' equivalent to upstream as expressed by
  the conflict-free merge. )

I believe the fact that the PTI patches have already been successfully backported 
to v4.9, with only minor additional cherry-picking, demonstrates that this is the 
right approach.

> I few things I noticed in the PTI tree:
> 
> "x86/mm/pti: Map ESPFIX into user space" has a leftover pr_err().
> Sorry, my bad, I've spent *way* too long looking at this crap to
> retain my sanity.  Also, if you're feeling like being super tidy, the
> init/main.c change in their could be folded in to whatever patch adds
> pti_init() in the first place, but it doesn't really matter.
> 
> "x86/pti: Map the vsyscall page if needed" has a change to
> pgtable_64.h that could be folded into an earlier patch.  This is
> probably my fault for applying Dave Hansen's cleanup request to the
> wrong patch.
> 
> "x86/mm/64: Make a full PGD-entry size hole in the memory map" would
> benefit from a mention of "5-level" somewhere in the subject or
> changelog.
> 
> In "x86/fixmap: Add debugstore entries to cpu_entry_area", I think the
> function "set_percpu_fixmap_ptes" is misnamed.  It should be something
> like "allocate_percpu_fixmap_ptes", perhaps, and it should either warn
> or do nothing if the PTE is already present, I think.  As it stands,
> it's a wee bit dangerous.
> 
> X86_BUG_CPU_SECURE_MODE_PTI should be added to DISABLED_FEATURES or
> DISABLED_BUGS or whatever if it's not configured in, which will reduce
> bloat.  Borislav, that's kind of up your alley, since I don't think
> the appropriate mask even exists right now.
> 
> 
> 
> Anyway, I stuck a few minor fixups here:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=x86/pti

Thanks, we'll integrate all of this!

Also note that regarding PTI LDT handling, our plan is to stick to the review 
feedback consensus: i.e. we'll apply your PTI LDT fixes as the initial approach, 
plus an optional series later on once PTI is upstream, with the VMA based bits by 
Thomas and PeterZ subject to a fresh round of thinking & evaluation. Even if we 
decide to do the VMA approach, I don't think that aspect of PTI will be 
backported.

This should further simplify logistics and offloads risks as well.

	Ingo