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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
> 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
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
.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 ch
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
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
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 {
>
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
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
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
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
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
.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 be e
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
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
> 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,
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 va
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
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
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
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
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 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
40 matches
Mail list logo
