linux-kernel - Re: [PATCH] ARM: supplementing IO accessors with 64 bit capability

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] [day] [month] [year] [list]

Date:	Tue, 28 Oct 2014 12:23:24 +0000
From:	Will Deacon <will.deacon@....com>
To:	Mathieu Poirier <mathieu.poirier@...aro.org>
Cc:	Catalin Marinas <Catalin.Marinas@....com>,
	"thomas.petazzoni@...e-electrons.com" 
	<thomas.petazzoni@...e-electrons.com>,
	"linux@....linux.org.uk" <linux@....linux.org.uk>,
	"stefano.stabellini@...citrix.com" <stefano.stabellini@...citrix.com>,
	Liviu Dudau <Liviu.Dudau@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"ezequiel.garcia@...e-electrons.com" 
	<ezequiel.garcia@...e-electrons.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] ARM: supplementing IO accessors with 64 bit capability

On Mon, Oct 27, 2014 at 10:14:41PM +0000, Mathieu Poirier wrote:
> On 27 October 2014 09:54, Will Deacon <will.deacon@....com> wrote:
> > On Fri, Oct 24, 2014 at 05:16:34PM +0100, Catalin Marinas wrote:
> >> As I said, it's confusing. Anyway, you can go ahead and add the
> >> readq/writeq for ARMv6 and later, though it won't be guaranteed to have
> >> a 64-bit access, it depends on the bus.
> >
> > I'm really not comfortable with this... we don't make any guarantees for
> > 32-bit CPUs that a double-word access will be single-copy atomic for MMIO.
> > That means it could be subjected to things like reordering and merging,
> > which I think means that it depends on both the bus *and* the endpoint as to
> > whether or not this will work. Worse still, the endpoint could decide to
> > return a SLVERR, which would appear as an external abort.
> 
> I agree on all of the point you bring up.  The person using these
> should know their architecture and the target endpoint support this
> kind of access.  If they don't then a problem will show up pretty
> quickly.

That goes against the I/O abstractions provided by the kernel to allow for
portable device drivers. readq/writeq *must* have some portable semantics
and I don't think that we should implement them on a best-effort basis
in io.h.

> >
> > Is it not possible to use 32-bit MMIO accesses for this driver?
> 
> Sure it is but we wouldn't be using the HW to it's full capability.
> Another solution is to move the accessors to the driver itself where
> nobody else in the 32 bit world will have access to them.  Russell,
> what you're opinion on that?

FWIW, I'd much prefer that, but I'd be interested to know how much of a
a couple of {read,write}l_relaxed operations really cost you by
comparison.

Will
--
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/