Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

2016-09-28 Thread Paulo Flabiano Smorigo
Wed, Sep 28, 2016 at 08:33:18PM +0800, Herbert Xu wrote: > On Wed, Sep 28, 2016 at 09:28:44AM -0300, Marcelo Cerri wrote: > > > > The big difference between p8_ghash and padlock_sha1 is that > > padlock_sha1 defines alg->statesize as sizeof(struct sha1_state), which > > is the descsize value used

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

2016-09-28 Thread Herbert Xu
On Wed, Sep 28, 2016 at 09:55:58AM -0300, Marcelo Cerri wrote: > > Great! If we check the descsize every time a fallback tfm is allocated > that should be enough to prevent bigger problems such as memory > corruptions. Yes a check wouldn't hurt. > Can I move ghash_desc_ctx to a header file

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

2016-09-28 Thread Marcelo Cerri
On Wed, Sep 28, 2016 at 08:44:52PM +0800, Herbert Xu wrote: > On Wed, Sep 28, 2016 at 09:38:41AM -0300, Marcelo Cerri wrote: > > > > The patch forces ghash-generic as the fallback. And I don't think that > > is a big problem if we decide to go by this path. > > Right it should work but could

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

2016-09-28 Thread Herbert Xu
On Wed, Sep 28, 2016 at 09:38:41AM -0300, Marcelo Cerri wrote: > > The patch forces ghash-generic as the fallback. And I don't think that > is a big problem if we decide to go by this path. Right it should work but could break for example if we ever decide to change the exported state structure

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

2016-09-28 Thread Marcelo Cerri
Hi Hebert, On Wed, Sep 28, 2016 at 08:29:35PM +0800, Herbert Xu wrote: > On Wed, Sep 28, 2016 at 03:40:51AM -0400, Jan Stancek wrote: > > > > Thanks for clearing up how this works in padlock-sha, but > > we are not exactly in same situation with p8_ghash. > > > > p8_ghash_init_tfm() already

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

2016-09-28 Thread Herbert Xu
On Wed, Sep 28, 2016 at 09:28:44AM -0300, Marcelo Cerri wrote: > > The big difference between p8_ghash and padlock_sha1 is that > padlock_sha1 defines alg->statesize as sizeof(struct sha1_state), which > is the descsize value used by sha1_generic. This probably works but > it's also wrong because

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

2016-09-28 Thread Herbert Xu
On Wed, Sep 28, 2016 at 03:40:51AM -0400, Jan Stancek wrote: > > Thanks for clearing up how this works in padlock-sha, but > we are not exactly in same situation with p8_ghash. > > p8_ghash_init_tfm() already updates descsize. Problem in original report > is that without custom

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

2016-09-28 Thread Marcelo Cerri
Hi Herbert, On Wed, Sep 28, 2016 at 10:45:49AM +0800, Herbert Xu wrote: > On Tue, Sep 27, 2016 at 04:46:44PM -0300, Marcelo Cerri wrote: > > > > Can you check if the problem occurs with this patch? > > In light of the fact that padlock-sha is the correct example > to follow, you only need to add

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

2016-09-28 Thread Jan Stancek
> Jan, > > Can you check if the problem occurs with this patch? No issues in over-night test with this patch. > --- a/drivers/crypto/vmx/vmx.c > +++ b/drivers/crypto/vmx/vmx.c > @@ -28,6 +28,8 @@ > #include > #include > > +int p8_ghash_fallback_descsize(void); > + > extern struct

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

2016-09-28 Thread Jan Stancek
gt;, > mhce...@linux.vnet.ibm.com, > leosi...@linux.vnet.ibm.com, pfsmor...@linux.vnet.ibm.com, > linux-cry...@vger.kernel.org, > linuxppc-...@lists.ozlabs.org, linux-kernel@vger.kernel.org > Sent: Wednesday, 28 September, 2016 4:45:49 AM > Subject: Re: [bug] crypto/vmx/p8_ghash memo

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

2016-09-27 Thread Herbert Xu
On Tue, Sep 27, 2016 at 04:46:44PM -0300, Marcelo Cerri wrote: > > Can you check if the problem occurs with this patch? In light of the fact that padlock-sha is the correct example to follow, you only need to add one line to the init_tfm fucntion to update the descsize based on that of the

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

2016-09-27 Thread Herbert Xu
On Tue, Sep 27, 2016 at 05:01:03AM -0400, Jan Stancek wrote: > > Also, does that mean that padlock_sha has similar problem? > It does not seem to reserve any space for fallback __ctx and it calls > init()/update()/export() with padlock_sha_desc's fallback: > > struct padlock_sha_desc { >

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

2016-09-27 Thread Marcelo Cerri
Jan, Can you check if the problem occurs with this patch? --- drivers/crypto/vmx/ghash.c | 28 +--- drivers/crypto/vmx/vmx.c | 9 + 2 files changed, 26 insertions(+), 11 deletions(-) diff --git a/drivers/crypto/vmx/ghash.c b/drivers/crypto/vmx/ghash.c index

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

2016-09-27 Thread Marcelo Cerri
Hi, On Tue, Sep 27, 2016 at 05:01:03AM -0400, Jan Stancek wrote: > So, if we extended p8_ghash_desc_ctx to accommodate fallback_desc's ctx > and then provided statesize/import/export, would that be acceptable? > > struct p8_ghash_desc_ctx { > ... > struct shash_desc

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

2016-09-27 Thread Jan Stancek
gt;, > mhce...@linux.vnet.ibm.com, > leosi...@linux.vnet.ibm.com, pfsmor...@linux.vnet.ibm.com, > linux-cry...@vger.kernel.org, > linuxppc-...@lists.ozlabs.org, linux-kernel@vger.kernel.org > Sent: Tuesday, 27 September, 2016 5:08:26 AM > Subject: Re: [bug] crypto/vmx/p8_ghash memo

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

2016-09-26 Thread Herbert Xu
On Mon, Sep 26, 2016 at 02:43:17PM -0300, Marcelo Cerri wrote: > > Wouldn't be enough to provide a pair of import/export functions as the > padlock-sha driver does? I don't think that will help as ultimately you need to call the export function on the fallback and that's what requires the extra

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

2016-09-26 Thread Jan Stancek
> leosi...@linux.vnet.ibm.com, pfsmor...@linux.vnet.ibm.com, > linux-cry...@vger.kernel.org, > linuxppc-...@lists.ozlabs.org, linux-kernel@vger.kernel.org > Sent: Monday, 26 September, 2016 4:15:10 PM > Subject: Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7 > > Hi Jan,

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

2016-09-26 Thread Marcelo Cerri
Herbert, Wouldn't be enough to provide a pair of import/export functions as the padlock-sha driver does? -- Regards, Marcelo On Mon, Sep 26, 2016 at 10:59:34PM +0800, Herbert Xu wrote: > On Fri, Sep 23, 2016 at 08:22:27PM -0400, Jan Stancek wrote: > > > > This seems to directly correspond

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

2016-09-26 Thread Herbert Xu
On Fri, Sep 23, 2016 at 08:22:27PM -0400, Jan Stancek wrote: > > This seems to directly correspond with: > p8_ghash_alg.descsize = sizeof(struct p8_ghash_desc_ctx) == 56 > shash_tfm->descsize = sizeof(struct p8_ghash_desc_ctx) + > crypto_shash_descsize(fallback) == 56 + 20 > where 20 is

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

2016-09-26 Thread Marcelo Cerri
Hi Jan, Just out of curiosity, have you tried to use "76" on both values to check if the problem still happens? -- Regards, Marcelo On Fri, Sep 23, 2016 at 08:22:27PM -0400, Jan Stancek wrote: > Hi, > > I'm chasing a memory corruption with 4.8-rc7 as I'm observing random Oopses > on ppc BE/LE

[bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

2016-09-23 Thread Jan Stancek
Hi, I'm chasing a memory corruption with 4.8-rc7 as I'm observing random Oopses on ppc BE/LE systems (lpars, KVM guests). About 30% of issues is that module list gets corrupted, and "cat /proc/modules" or "lsmod" triggers an Oops, for example: [ 88.486041] Unable to handle kernel paging