linux-kernel - Re: [RFC GIT PULL] x86 Page Table Isolation (PTI) syscall entry code preparatory patches

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 17 Dec 2017 00:46:31 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        Andy Lutomirski <luto@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC GIT PULL] x86 Page Table Isolation (PTI) syscall entry code
 preparatory patches


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Fri, Dec 15, 2017 at 5:58 PM, Ingo Molnar <mingo@...nel.org> wrote:
> >
> > These are the x86-64 low level entry code preparatory patches for the page table
> > isolation patches - which are required for PTI, which addresses KASLR and similar
> > information leaks.
> 
> Ugh.
> 
> Ok, I've read through this, and while I like most of it (I do like the
> percpu syscall stack), I have this urge to wait until after rc4. With
> the suspend/resume issues,

Yeah, so as a response to those breakages I recently started testing s2ram as a 
regular part of -tip testing, so every tree I send to you does s2ram fine on my 
(suspendable) testsystems. That's still not full coverage, but should be better 
than what we had.

> [...] we've had a horrible track record for 4.15 rc's so far, I'l like to not 
> pull another low-level x86 change just before an rc release and potentially make 
> it four for four broken rc's.

Yeah, I can understand that. I knew the weekend timing is awkward, but I tried to 
post it as soon as I felt it was ready and as soon upstream (x86) stability looked 
good.

> And I absolutely detest how that cherry-pick branch was done. I can
> see why, but:
> 
>  - now we have those extra cherry-picks that I already have
> 
>  - and the merge commit isn't even a no-op!
> 
> Dammit, if the point was to have a branch that worked for 4.14, I can
> see that. But look at that merge (on the "other side"), and notice how
> the end result is *not* identical to the parent.
> 
> IOW, that
> 
>   9a818d1a3235 Merge branch 'WIP.x86/pti.base' into x86/pti, to pick
> up cherry-picked base tree and preparatory patches
> 
> was supposed to be a synchronization point, but if you do
> 
>     git diff 9a818d1a3235..9a818d1a3235^
> 
> it isn't actually synchronized. It's *almost* synchronized, but not
> quite. How did those cherry-picks that were already upstream end up
> causing *changes* upstream? That's odd.
> 
> So there are some technical oddities in there.

Indeed, and I tried to make it a no-op merge, and it's _almost_ a no-op merge, 
except these two commits:

One of the PTI namespace preparatory patches ended up in the 'base' tree:

  d78b637b29a2: drivers/misc/intel/pti: Rename the header file to free up the namespace

plus there's this cherry-pick from a very recent upstream kernel:

  c3bc8b53d54c: bpf: fix build issues on um due to mising bpf_perf_event.h

which was required for UML to build and be testable.

We can move both commits to a later stage in the tree to make the v4.14 base tree 
an 'obvious' upstream-identical tree.

Will respin it all tomorrow.

Thanks,

	Ingo