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 b
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 unde
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 brea
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 f
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 upda
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 t
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 export/import/stat
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 o
> 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 shash_al
.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 memory corruption in 4.8-rc7
>
> On Tue, Sep 27, 2016 at 04:46:44PM -0300, Marcelo Cerri wrote:
> >
> > Can you check
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 fallba
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 {
>
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 6
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 fallback_desc;
.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 memory corruption in 4.8-rc7
>
> On Mon, Sep 26, 2016 at 02:43:17PM -0300, Marcelo Cerri wrote:
> >
> > Wouldn't
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
m
g,
> 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,
>
> Just out of curiosity, have you tried to use "76" on both values to
&g
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 with:
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 presum
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
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 request
21 matches
Mail list logo