From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail.kernel.org ([198.145.29.99]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fJe7J-0000Ap-Mp for speck@linutronix.de; Fri, 18 May 2018 14:04:14 +0200 Date: Fri, 18 May 2018 14:03:48 +0200 From: Greg KH Subject: [MODERATED] Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2 Message-ID: <20180518120348.GC5632@kroah.com> References: <20180517031815.016936086@localhost.localdomain> <20180518114345.GU18423@char.us.oracle.com> MIME-Version: 1.0 In-Reply-To: <20180518114345.GU18423@char.us.oracle.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Fri, May 18, 2018 at 07:43:45AM -0400, speck for Konrad Rzeszutek Wilk wrote: > On Fri, May 18, 2018 at 11:14:51AM +0200, speck for Thomas Gleixner wrote: > > On Wed, 16 May 2018, speck for konrad.wilk_at_oracle.com wrote: > > > > > xen: Don't call non-Xen routines early in the boot > > > > > > Commit 2cc42bac1c79 ("x86-64/Xen: eliminate W+X mappings") added a call > > > to get_cpu_cap() to properly set boot_cpu_has(X86_FEATURE_NX) which is > > > needed to correctly initialize __supported_pte_mask. Doing this so early > > > in the boot can be dangerous --- while this currently works, there is no > > > telling what get_cpu_cap() may decide to add in the future. For example, > > > if it decides to do a printk (which is not something impossible to > > > imagine) a PV guest will not be able to cope with it. > > > > So this is not an issue today and I don't see a reason why you need to add > > open coded hackery. > > > > > + /* Work out if we support NX. */ > > > + if ((cpuid_eax(0x80000000) >= 0x80000001) && > > > + (cpuid_edx(0x80000001) & (1U << (X86_FEATURE_NX & 31)))) > > > + __supported_pte_mask |= _PAGE_NX; > > > + else > > > + __supported_pte_mask &= ~_PAGE_NX; > > > + > > > > And of course this open coded hack is not a 1:1 replacement for > > x86_configure_nx(). > > > > So can you please explain what kind of problem you are trying to solve? > > This SSB patch series makes Xen PV guests crash. Which exact patch causes the crash? Why not fix that one up instead to not break things. That seems like a wiser thing to do instead of papering over it later on in a patch series to be applied at some later date. > > AFAICT from the changelog it's just the 'someone might add a printk' > > fear. Come on, that's silly. If that happens its going to be caught in next > > early enough to fix it. > > That is more of a obfuscation in case you would like this particular patch > go through the not-secure-channel. As this is a "secure channel", you are causing confusion here :( thanks, greg k-h