On Sun, Jan 14, 2018 at 10:40:36PM +0100, Arnd Bergmann wrote:
> Right. I've done some more investigation anyway, starting over with the
> analysis of the gcc options that change it. I've found now that turning
> off '-fcode-hoisting' but leaving on the other options I had suspected
> earlier (-O2
On Fri, Jan 12, 2018 at 10:45:31PM +0100, Arnd Bergmann wrote:
> > I guess you could enable the _x routines whenever you use ubsan? Ubsan
> > will cause much bigger code growth than the handful of insns in those
> > routines?
>
> Right, that could work, too. My patch that Herbert merged intention
On Fri, Jan 12, 2018 at 10:29:01PM +0100, Arnd Bergmann wrote:
> On Fri, Jan 12, 2018 at 9:41 PM, Segher Boessenkool
> wrote:
> > On Fri, Jan 12, 2018 at 08:43:21PM +0100, Arnd Bergmann wrote:
> >> On Fri, Jan 12, 2018 at 5:39 PM, Segher Boessenkool
>
> >> We c
On Fri, Jan 12, 2018 at 08:43:21PM +0100, Arnd Bergmann wrote:
> On Fri, Jan 12, 2018 at 5:39 PM, Segher Boessenkool
> wrote:
>
> >> or why the aes_generic implementation needs this on
> >> powerpc when built with 'gcc -Os'. FWIW, the -Os change was needed
Hi!
On Fri, Jan 12, 2018 at 03:55:47PM +0100, Arnd Bergmann wrote:
> >crypto/aes_generic.o: In function `crypto_aes_set_key':
> >>> aes_generic.c:(.text+0x4e0): undefined reference to `_restgpr_31_x'
>
> adding linuxpcc-dev to Cc, maybe someone knows a way out of this.
> It appears related to
Hi Anton,
On Fri, Jul 01, 2016 at 08:19:45AM +1000, Anton Blanchard wrote:
> +#ifdef BYTESWAP_DATA
> + addis r3,r2,.byteswap_constant@toc@ha
> + addir3,r3,.byteswap_constant@toc@l
> +
> + lvx byteswap,0,r3
> + addir3,r3,16
> +#endif
You already have r0=0, so you can
On Sat, Dec 12, 2015 at 03:01:26PM -0800, Haren Myneni wrote:
> On 12/12/2015 12:43 AM, Segher Boessenkool wrote:
> > On Fri, Dec 11, 2015 at 07:30:29PM -0800, Haren Myneni wrote:
> >> NX842 coprocessor sets 3rd bit in CR register with XER[S0] which is
> >> nothin
On Fri, Dec 11, 2015 at 07:30:29PM -0800, Haren Myneni wrote:
> NX842 coprocessor sets 3rd bit in CR register with XER[S0] which is
> nothing to do with NX request. On powerpc, XER[S0] will be set if
> overflow in FPU and stays until another floating point operation is
> executed. Since this bit ca
On Mon, Feb 16, 2015 at 02:19:50PM +, David Laight wrote:
> From: Markus Stockhausen
> > 4K AES tables for big endian
>
> I can't help feeling that you could give more information about how the
> values are generated.
... and an explanation of why this does not open you up to a timing attack
