[MODERATED] Re: [PATCH v5 6/8] NX 6

mark gross <[email protected]> Mon, 4 Nov 2019 11:43:51 -0800
Newsgroups org.kernel.lore.historical-speck
Message-ID <20191104194351.GA18351@u1904>
On Sun, Oct 13, 2019 at 11:11:05PM +0100, speck for Ben Hutchings wrote:
> On Thu, 2019-10-10 at 01:08 +0200, speck for Paolo Bonzini wrote:
> > On 10/10/19 00:42, speck for Ben Hutchings wrote:
> > > I've started trying to backport the NX patches to stable branches, and
> > > I think I can take them back as far as 4.9.
> > > 
> > > However, kvm_mmu_zap_all() is a relatively new addition and looks hard
> > > to backport.  I intend to make the nx_huge_pages parameter read-only
> > > (0444 permissions) and delete this "if (new_val != old_val)" block. 
> > > Does that seem reasonable?
> > 
> > Just replace it with kvm_mmu_invalidate_zap_all_pages (which will be in 
> > v6, because we have since brought it back from the dead).
> > 
> > You also have to backport commit 833b45de69a6 ("kvm: x86, powerpc: do 
> > not allow clearing largepages debugfs entry", 2019-09-30) and make the 
> > new statistic 0444 as well.  This is the only other change in v6 for now.
> > 
> > This is the list of prerequisites I had prepared, it should go back to 4.3 or so:
> 
> Wow, thanks for this.  I still don't think it's worthwile to backport
> this mitigation to stable branches older than 4.9 - they never got KVM
> mitigations for L1TF so they're already unsuitable for hosting
> untrusted guests.  After excluding commits older than 4.9, the list is
> then:

If you have some backports of the NX changes we have some testing setups to
check them out if you can share the work over this list.

I think I will attempt the 4.4 backport for the NX issue as its more of an
errata than a side channel thing.

If someone already has a 4.4 backport done we can help check it out.

Thanks,

--mark


> 
> [...]
> > e08d26f0712532c79b5ba6200862eaf2036f8df6 kvm: x86: simplify ept_misconfig
> > 9b8ebbdb74b5ad76b9dfd8b101af17839174b126 kvm: x86: extend usage of RET_MMIO_PF_* constants
> > 42522d08cdba6d8be4247e4f0770f39f4708b71f KVM: MMU: drop vcpu param in gpte_access
> > 0d9ce162cf46c99628cc5da9510b959c7976735b kvm: Convert kvm_lock to a mutex
> [...]
> > 43fdcda96e2550c6d1c46fb8a78801aa2f7276ed kvm: mmu: Do not release the page inside mmu_set_spte() 
> > 9de2b2120668d2874570b14105e49235097b70c2 KVM: x86: make FNAME(fetch) and __direct_map more similar
> 
> Commit hash should be 3fcf2d1bdeb6a513523cb2c77012a6b047aa859c?
> 
> > d679b32611c0102ce33b9e1a4e4b94854ed1812a KVM: x86: remove now unneeded hugepage gfn adjustment 
> > 1e823556fd3af3635e174f570d0b85b4e72b2b1c KVM: x86: change kvm_mmu_page_get_gfn BUG_ON to WARN_ON
> 
> Commit hash should be e9f2a760b158551bfbef6db31d2cae45ab8072e5?
> 
> > bf9af89c4146978000eba9b0a1eb43540d893223 KVM: x86: add tracepoints around __direct_map and FNAME(fetch)
> 
> Commit hash should be 335e192a3fa415e1202c8b9ecdaaecd643f823cc?
> 
> > 833b45de69a6016c4b0cebe6765d526a31a81580 kvm: x86, powerpc: do not allow clearing largepages debugfs entry
> > 
> > None of the backports should be particularly tricky.
> 
> In my previous attempt I found it helpful to pick these two that you
> didn't mention:
> 
> 3ff519f29d98 KVM: x86: adjust kvm_mmu_page member to save 8 bytes
> 00ae831dfe44 x86/cpu: Add Atom Tremont (Jacobsville)
> 
> Ben.
> 
> -- 
> Ben Hutchings
> The obvious mathematical breakthrough [to break modern encryption]
> would be development of an easy way to factor large prime numbers.
>                                                            - Bill Gates
>