linux-kernel - Re: [PATCH v5 10/12] x86/xen: Bypass intr mode setup in enlighten

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:   Mon, 3 Jul 2017 08:56:13 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Dou Liyang <douly.fnst@...fujitsu.com>
cc:     x86@...nel.org, linux-kernel@...r.kernel.org,
        xen-devel@...ts.xenproject.org, mingo@...nel.org, hpa@...or.com,
        ebiederm@...ssion.com, bhe@...hat.com, boris.ostrovsky@...cle.com,
        peterz@...radead.org, izumi.taku@...fujitsu.com
Subject: Re: [PATCH v5 10/12] x86/xen: Bypass intr mode setup in enlighten_pv
 system

On Mon, 3 Jul 2017, Dou Liyang wrote:
> At 07/03/2017 03:18 AM, Thomas Gleixner wrote:
> > On Fri, 30 Jun 2017, Dou Liyang wrote:
> > 
> > > xen_smp_ops overwrites smp_prepare_cpus to xen_pv_smp_prepare_cpus
> > > which initializes interrupt itself.
> > > 
> > > Touching the intr_mode_init causes unexpected results on the system.
> > > 
> > > Bypass it in enlighten_pv system.
> > 
> > So that's the wrong patch order then. You broke XEN at some point with your
> > changes. You need to prevent that breakage upfront not after the fact.
> 
> Yes, I have considered to prevent that breakage in the patchset.
> 
> Actually, Until the 11th patch, we put the intr_mode_init ahead of
> time, which will break XEN.
> 
> Before the 11th patch, we just unify the code and do the preparation,
> Kernel will do the intr_mode_init like before, which will have no
> influence on XEN.
> 
> So we put the patch here before 11th patch.

Ok. That's good, but please explain it in the changelog. I had the
impression that this is fixing breakage you introduced earlier, but now
with your explanation it makes sense. So the patch order is correct.

Something like this wants to be in the changelog:

  XEN PV overrides smp_prepare_cpus(). xen_pv_smp_prepare_cpus()
  initializes interrupts in the XEN PV specific way and does not invoke
  native_smp_prepare_cpus(). As a consequence, x86_init.intr_mode_init() is
  not invoked either.

  The invocation of x86_init.intr_mode_init() will be moved from
  native_smp_prepare_cpus() in a follow up patch to solve <INSERT
  REASON/PROBLEM>.

  That move would cause the invocation of x86_init.intr_mode_init() for XEN
  PV platforms. To prevent that, override the default x86_init.intr_mode_init()
  callback with a noop().

Thanks,

	tglx