linux-kernel - Re: [PATCH] powerpc: process.c: fix Kconfig typo

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

Date:   Thu, 27 Oct 2016 12:08:31 +1100
From:   Cyril Bur <cyrilbur@...il.com>
To:     Michael Ellerman <mpe@...erman.id.au>,
        Valentin Rothberg <valentinrothberg@...il.com>
Cc:     linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH] powerpc: process.c: fix Kconfig typo

On Wed, 2016-10-26 at 16:52 +1100, Michael Ellerman wrote:
> Cyril Bur <cyrilbur@...il.com> writes:
> 
> > On Wed, 2016-10-05 at 07:57 +0200, Valentin Rothberg wrote:
> > > s/ALIVEC/ALTIVEC/
> > > 
> > 
> > Oops, nice catch
> > 
> > > Signed-off-by: Valentin Rothberg <valentinrothberg@...il.com>
> > 
> > Reviewed-by: Cyril Bur <cyrilbur@...il.com>
> 
> How did we not notice? Sounds like we need a new selftest.
> 

Indeed...

Here is probably a good place to say why we didn't catch it and under
what circumstances this will have a negative effect.

If a thread performs and transaction with altivec and then gets
preempted for whatever reason, this bug may cause the kernel to not
reenable altivec when that thread runs again. This will result in an
altivec unavailable fault, when these faults happen inside a user
transaction the kernel has no choice but enable altivec and doom the
transaction.

The result is that transactions using altivec may get aborted more than
they should.

The difficulty in catching this with a selftest is my deliberate use of
the word may above. Optimisations to avoid FPU/altivec/VSX faults mean
that the kernel will always leave them on for 255 switches, this code
prevents the kernel turning it off if it got to the 256th switch (and
userspace was transactional)...

Cyril

> Looks like this should have:
> 
> Fixes: dc16b553c949 ("powerpc: Always restore FPU/VEC/VSX if hardware
> transactional memory in use")
> 
> 
> And I guess I need to start running checkkconfigsymbols.py on every
> commit.
> 
> cheers