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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 19 Apr 2013 18:06:01 +0100
From:	Stefano Stabellini <stefano.stabellini@...citrix.com>
To:	Nicolas Pitre <nicolas.pitre@...aro.org>
CC:	Ian Campbell <Ian.Campbell@...rix.com>,
	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 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.

If we don't take further precautions I'll be forced to regularly scan
the list for smp_init implementations and look for possible breakages,
pointing the unaware author of the patches to this conversation.
Honestly it is not my idea of fun.


> And if Xen wants to emulate one of those hardware alternatives, then it 
> better be ready to emulate it properly, or manage for _another_ mdesc to 
> be selected instead.  That's why mach-virt was introduced.

I don't mean to argue pointlessly here, but I thought that it was clear
that Xen does not emulate any hardware interfaces at all.

Of course when a convenient virtualization aware hardware interface is
available (the vGIC for example) Xen is going to use it, but other than
that no emulation is going to be done.


> So in my opinion there is just no issue here.

Not now, and maybe not even in the near future.
But I feel that we are taking an error prone approach.
--
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/