linux-kernel - Re: [PATCH 1/6] openrisc: add Kconfig for l.lwa and l.swa atomic instructions

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:	Thu, 24 Jul 2014 22:52:39 +0300
From:	Stefan Kristiansson <stefan.kristiansson@...nalahti.fi>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	linux-kernel@...r.kernel.org, linux@...nrisc.net,
	jonas@...thpole.se
Subject: Re: [PATCH 1/6] openrisc: add Kconfig for l.lwa and l.swa atomic
 instructions

On Wed, Jul 23, 2014 at 10:26:01PM +0100, One Thousand Gnomes wrote:
> > +config OPENRISC_HAVE_INST_LWA_SWA
> > +	bool "Have instruction l.lwa and l.swa"
> > +	help
> > +	  Select this if your implementation have l.lwa and l.swa atomic
> > +	  instructions.
> > +
> >  endmenu
> 
> Please do everyone a favour - sort all these out at runtime, add an
> architectural feature bits ROM address or catch the traps and use the
> alterntatives logic or something.
> 

Detecting whether the instruction exists is of course trivial,
the hard part is what to do with this information at runtime.
My initial intention was to add emulation for the l.lwa and l.swa
instructions in the kernel, so a CPU without them would still
be able to run a kernel with CONFIG_OPENRISC_HAVE_INST_LWA_SWA enabled,
but inefficiently.

I will in either case add the kernel emulation,
since it's still needed to handle userspace occurences of these
instructions, perhaps that patch belong to this series as well.

I wasn't familiar with the alternatives logic before, so I had
to look it up.
Correct me if I'm wrong, but from what I gathered, the approach
that takes is especially suitable to fixup instructions that
are similar to each others but have slightly different properties
(the lock prefix to cmpxchg being the canonical example).

I guess it'd be *possible* to still use this method to implement
alternatives that would work in the UP case by disabling
context-switch and perform normal loads and stores in place
of the l.lwa and l.swa instructions, but is it really a good approach?

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