linux-kernel - Re: [PATCH] powerpc: define empty enable_kernel_vsx() when CONFIG

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:	Wed, 09 Sep 2015 12:13:50 +1000
From:	Michael Ellerman <mpe@...erman.id.au>
To:	Tim Gardner <tim.gardner@...onical.com>
Cc:	Paul Mackerras <paulus@...abs.org>, linuxppc-dev@...ts.ozlabs.org,
	linux-kernel@...r.kernel.org,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Leonidas Da Silva Barbosa <leosilva@...ux.vnet.ibm.com>,
	Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: [PATCH] powerpc: define empty enable_kernel_vsx() when
 CONFIG_VSX=n

On Tue, 2015-09-08 at 17:19 -0600, Tim Gardner wrote:
> On 09/08/2015 04:47 PM, Paul Mackerras wrote:
> > On Tue, Sep 08, 2015 at 12:13:11PM -0600, tim.gardner@...onical.com wrote:
> >> From: Tim Gardner <tim.gardner@...onical.com>
> >>
> >> commit 72cd7b44bc99 ("powerpc: Uncomment and make enable_kernel_vsx()
> >> routine available") neglected to define an empty inline replacement for
> >> enable_kernel_vsx() when CONFIG_VSX=n.
> > 
> > If code that wants to call enable_kernel_vsx() is getting compiled in
> > when CONFIG_VSX=n, that's a worry.  Is this patch motivated by an
> > actual compile failure?  If so what was the failure?
> 
> I was having link failures after backporting 'crypto: nx' patches to a
> 4.2 based kernel. You may have a point in that the upstream Kconfig will
> not allow those files to be compiled if CONFIG_VSX=n. I will check in my
> morning if to see if I can reproduce the same link error in mainline.

I suspect the problem is the "vmx" crypto actually.

$ git grep enable_kernel_vsx drivers/
drivers/crypto/vmx/aes.c:       enable_kernel_vsx();
drivers/crypto/vmx/aes.c:               enable_kernel_vsx();
drivers/crypto/vmx/aes.c:               enable_kernel_vsx();
drivers/crypto/vmx/aes_cbc.c:   enable_kernel_vsx();
drivers/crypto/vmx/aes_cbc.c:           enable_kernel_vsx();
drivers/crypto/vmx/aes_cbc.c:           enable_kernel_vsx();
drivers/crypto/vmx/aes_ctr.c:   enable_kernel_vsx();
drivers/crypto/vmx/aes_ctr.c:   enable_kernel_vsx();
drivers/crypto/vmx/aes_ctr.c:                   enable_kernel_vsx();
drivers/crypto/vmx/ghash.c:     enable_kernel_vsx();
drivers/crypto/vmx/ghash.c:                     enable_kernel_vsx();
drivers/crypto/vmx/ghash.c:                     enable_kernel_vsx();
drivers/crypto/vmx/ghash.c:                     enable_kernel_vsx();


That appears to all be controlled by CONFIG_CRYPTO_DEV_VMX_ENCRYPT, which
depends on CONFIG_CRYPTO_DEV_VMX, which depends on PPC64.

So that looks like it will break terribly if VSX is turned off.

We do have an automated test build with VSX turned off, but it doesn't have
CONFIG_CRYPTO_DEV_VMX enabled :/


Having said all that, why are you building a ppc64 kernel with VSX turned off?

cheers


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