linux-kernel - Re: [Xen-devel] [PATCH v6 1/4] arm: introduce psci_smp

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 for Android: free password hash cracker in your pocket

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

Message-ID: <alpine.LFD.2.03.1304221151200.17375@syhkavp.arg>
Date:	Mon, 22 Apr 2013 12:07:23 -0400 (EDT)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Ian Campbell <Ian.Campbell@...rix.com>
cc:	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	"arnd@...db.de" <arnd@...db.de>,
	"marc.zyngier@....com" <marc.zyngier@....com>,
	"will.deacon@....com" <will.deacon@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [Xen-devel] [PATCH v6 1/4] arm: introduce psci_smp_ops

On Mon, 22 Apr 2013, Ian Campbell wrote:

> On Fri, 2013-04-19 at 18:06 +0100, Stefano Stabellini wrote:
> > On Fri, 19 Apr 2013, Nicolas Pitre wrote:
> > > On Fri, 19 Apr 2013, Ian Campbell wrote:
> > > 
> > > > On Fri, 2013-04-19 at 16:47 +0100, Nicolas Pitre wrote:
> > > > > No one should be probing registers without making sure it is safe to do 
> > > > > so.  Even on non virtualized hardware this can be a dangerous thing to 
> > > > > do.
> > > > 
> > > > Won't people writing per machine code consider, not unreasonably, that
> > > > having been called through a mdesc machine specific hook constitutes
> > > > enough "making sure" that they think it is safe to touch registers which
> > > > are specific to that machine?
> > > 
> > > Remember that this hook was introduced to decide at run time between 
> > > different possibilities for SMP ops on the _same_ machine configuration.  
> > > That machine shouldn't do things which is not permitted on either 
> > > possible alternatives already.  So far the actual usage of that hook 
> > > only looks in the DT to make a decision.  But even if it were to touch 
> > > the hardware, that means it has to be safe to do so on all the possible 
> > > hardware variations this mdesc is associated to.
> > 
> > This last sentence is the key.
> > 
> > It is not guaranteed that being safe on "all the possible hardware
> > variations this mdesc is associated to" and being safe on Xen are the
> > same thing.
> > 
> > What if the same magic configuration register exists on all the possible
> > variations of the platform?
> > I understand that it is unlikely but I think it is a possibility.
> 
> I think it is actually quite likely for such configuration registers,
> nvram etc to exist on all variants of a platform and not all that
> unlikely that smp_init might want to consult them.

In which case the rest of the kernel is also going to consult those 
registers for other purposes.

Again, what's the problem please?

> I think the key thing that non-Xen folks aren't aware of is that
> although Xen passes the majority of the underlying hardware to the dom0
> kernel to manage one of the few things it does not expose to guests
> (where "guests" includes dom0) is the SMP topology of the underlying system.

I suspect it is unlikely to pass on the DT information about the CCI 
either.  Which means that, in the case that started this thread, the 
smp_init function needed by MCPM will simply return false and the next 
priority in the list i.e. plain PSCI will be initialized instead.

I don't forsee the need to poke at the hardware directly within 
->smp_init, not since everything is moving to DT now.

Sure there are ways to screw up Xen support from within this hook, but 
that can be achieved in many other places.  Will Xen take over every 
possible hooks in the kernel to prevent that from happening?

So please let's not cry wolf needlessly.

> Currently the VCPUs are all considered to be uniform i.e. there is no
> big.LITTLE exposed to guests, although the hypervisor will most likely
> eventually support it and so may be scheduling the VCPUs among the big
> and LITTLE PCPUs according to $THINGS.

Indeed.  That's what I suggested earlier.


Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/