The AES GCM function reuses an 'op' data structure, which members
contain values that must be cleared for each (re)use.
Fixes: 36cf515b9bbe ("crypto: ccp - Enable support for AES GCM on v5 CCPs")
Signed-off-by: Gary R Hook <[email protected]>
---
drivers/crypto/ccp/ccp-ops.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/ccp/ccp-ops.c b/drivers/crypto/ccp/ccp-ops.c
index b116d62991c6..695522b2ba7f 100644
--- a/drivers/crypto/ccp/ccp-ops.c
+++ b/drivers/crypto/ccp/ccp-ops.c
@@ -626,6 +626,7 @@ static int ccp_run_aes_gcm_cmd(struct ccp_cmd_queue *cmd_q,
unsigned long long *final;
unsigned int dm_offset;
+ unsigned int jobid;
unsigned int ilen;
bool in_place = true; /* Default value */
int ret;
@@ -664,9 +665,11 @@ static int ccp_run_aes_gcm_cmd(struct ccp_cmd_queue *cmd_q,
p_tag = scatterwalk_ffwd(sg_tag, p_inp, ilen);
}
+ jobid = CCP_NEW_JOBID(cmd_q->ccp);
+
memset(&op, 0, sizeof(op));
op.cmd_q = cmd_q;
- op.jobid = CCP_NEW_JOBID(cmd_q->ccp);
+ op.jobid = jobid;
op.sb_key = cmd_q->sb_key; /* Pre-allocated */
op.sb_ctx = cmd_q->sb_ctx; /* Pre-allocated */
op.init = 1;
@@ -817,6 +820,13 @@ static int ccp_run_aes_gcm_cmd(struct ccp_cmd_queue *cmd_q,
final[0] = cpu_to_be64(aes->aad_len * 8);
final[1] = cpu_to_be64(ilen * 8);
+ memset(&op, 0, sizeof(op));
+ op.cmd_q = cmd_q;
+ op.jobid = jobid;
+ op.sb_key = cmd_q->sb_key; /* Pre-allocated */
+ op.sb_ctx = cmd_q->sb_ctx; /* Pre-allocated */
+ op.init = 1;
+ op.u.aes.type = aes->type;
op.u.aes.mode = CCP_AES_MODE_GHASH;
op.u.aes.action = CCP_AES_GHASHFINAL;
op.src.type = CCP_MEMTYPE_SYSTEM;
Hi Gary,
On Wed, Jul 03, 2019 at 07:21:26PM +0000, Hook, Gary wrote:
> The AES GCM function reuses an 'op' data structure, which members
> contain values that must be cleared for each (re)use.
>
> Fixes: 36cf515b9bbe ("crypto: ccp - Enable support for AES GCM on v5 CCPs")
>
> Signed-off-by: Gary R Hook <[email protected]>
> ---
> drivers/crypto/ccp/ccp-ops.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
Is this patch meant to fix the gcm-aes-ccp self-tests failure?
- Eric
On 7/5/19 2:40 PM, Eric Biggers wrote:
> Hi Gary,
>
> On Wed, Jul 03, 2019 at 07:21:26PM +0000, Hook, Gary wrote:
>> The AES GCM function reuses an 'op' data structure, which members
>> contain values that must be cleared for each (re)use.
>>
>> Fixes: 36cf515b9bbe ("crypto: ccp - Enable support for AES GCM on v5 CCPs")
>>
>> Signed-off-by: Gary R Hook <[email protected]>
>> ---
>> drivers/crypto/ccp/ccp-ops.c | 12 +++++++++++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> Is this patch meant to fix the gcm-aes-ccp self-tests failure?
Yessir, that is the intention. Apologies for not clarifying that point.
grh
On Mon, Jul 08, 2019 at 05:08:09PM +0000, Gary R Hook wrote:
> On 7/5/19 2:40 PM, Eric Biggers wrote:
> > Hi Gary,
> >
> > On Wed, Jul 03, 2019 at 07:21:26PM +0000, Hook, Gary wrote:
> >> The AES GCM function reuses an 'op' data structure, which members
> >> contain values that must be cleared for each (re)use.
> >>
> >> Fixes: 36cf515b9bbe ("crypto: ccp - Enable support for AES GCM on v5 CCPs")
> >>
> >> Signed-off-by: Gary R Hook <[email protected]>
> >> ---
> >> drivers/crypto/ccp/ccp-ops.c | 12 +++++++++++-
> >> 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > Is this patch meant to fix the gcm-aes-ccp self-tests failure?
>
> Yessir, that is the intention. Apologies for not clarifying that point.
>
> grh
>
>
Okay, it would be helpful if you'd explain that in the commit message.
Also, what branch does this patch apply to? It doesn't apply to cryptodev.
- Eric
On 7/9/19 3:10 PM, Eric Biggers wrote:
> On Mon, Jul 08, 2019 at 05:08:09PM +0000, Gary R Hook wrote:
>> On 7/5/19 2:40 PM, Eric Biggers wrote:
>>> Hi Gary,
>>>
>>> On Wed, Jul 03, 2019 at 07:21:26PM +0000, Hook, Gary wrote:
>>>> The AES GCM function reuses an 'op' data structure, which members
>>>> contain values that must be cleared for each (re)use.
>>>>
>>>> Fixes: 36cf515b9bbe ("crypto: ccp - Enable support for AES GCM on v5 CCPs")
>>>>
>>>> Signed-off-by: Gary R Hook <[email protected]>
>>>> ---
>>>> drivers/crypto/ccp/ccp-ops.c | 12 +++++++++++-
>>>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>>
>>> Is this patch meant to fix the gcm-aes-ccp self-tests failure?
>>
>> Yessir, that is the intention. Apologies for not clarifying that point.
>>
>> grh
>
> Okay, it would be helpful if you'd explain that in the commit message.
Gah. Of course. I'll repost.
> Also, what branch does this patch apply to? It doesn't apply to cryptodev.
I have endeavored to make a "git pull" and a full build a required,
regular part of my submission process, having made (plenty of) mistakes
in the past. I did so last week before posting this, and the patch
applied then, and applies now in my local copy, before and after a git
pull today.
We've been having trouble with our SMTP mail server, and patches have
been going out base64 encoded. I'm willing to bet that's what you're
wrestling with.
The last patch of mine that Herbert applied appeared to be encoded
thusly, but he was able to successfully apply it.
I've been experimenting with changing the transfer encoding value
(charset=) to iso-8859-1 and us-ascii, but the best I can do is an
encoding that contains a lot of "=##" stuff. I'm not sure that's any
better, but my recent documentation patches contained those, and Herbert
was also able to apply them.
We'd really like to know what Herbert does to accommodate these
non-textual emails? And is that something that others could do?
grh
On Tue, Jul 09, 2019 at 10:09:16PM +0000, Gary R Hook wrote:
> On 7/9/19 3:10 PM, Eric Biggers wrote:
> > On Mon, Jul 08, 2019 at 05:08:09PM +0000, Gary R Hook wrote:
> >> On 7/5/19 2:40 PM, Eric Biggers wrote:
> >>> Hi Gary,
> >>>
> >>> On Wed, Jul 03, 2019 at 07:21:26PM +0000, Hook, Gary wrote:
> >>>> The AES GCM function reuses an 'op' data structure, which members
> >>>> contain values that must be cleared for each (re)use.
> >>>>
> >>>> Fixes: 36cf515b9bbe ("crypto: ccp - Enable support for AES GCM on v5 CCPs")
> >>>>
> >>>> Signed-off-by: Gary R Hook <[email protected]>
> >>>> ---
> >>>> drivers/crypto/ccp/ccp-ops.c | 12 +++++++++++-
> >>>> 1 file changed, 11 insertions(+), 1 deletion(-)
> >>>
> >>> Is this patch meant to fix the gcm-aes-ccp self-tests failure?
> >>
> >> Yessir, that is the intention. Apologies for not clarifying that point.
> >>
> >> grh
> >
> > Okay, it would be helpful if you'd explain that in the commit message.
>
> Gah. Of course. I'll repost.
>
> > Also, what branch does this patch apply to? It doesn't apply to cryptodev.
>
> I have endeavored to make a "git pull" and a full build a required,
> regular part of my submission process, having made (plenty of) mistakes
> in the past. I did so last week before posting this, and the patch
> applied then, and applies now in my local copy, before and after a git
> pull today.
>
> We've been having trouble with our SMTP mail server, and patches have
> been going out base64 encoded. I'm willing to bet that's what you're
> wrestling with.
>
> The last patch of mine that Herbert applied appeared to be encoded
> thusly, but he was able to successfully apply it.
>
> I've been experimenting with changing the transfer encoding value
> (charset=) to iso-8859-1 and us-ascii, but the best I can do is an
> encoding that contains a lot of "=##" stuff. I'm not sure that's any
> better, but my recent documentation patches contained those, and Herbert
> was also able to apply them.
>
> We'd really like to know what Herbert does to accommodate these
> non-textual emails? And is that something that others could do?
>
What I did was simply save your email and use 'git am -3' to try to apply it.
It didn't work.
Yes, your email is base64 encoded, which apparently 'git am' handles. But even
after base64 decoding your patch has an extra blank line at the end, which
corrupts it since it's part of the diff context.
Can't you just use git send-email like everyone else?
- Eric
On 7/9/19 5:56 PM, Eric Biggers wrote:
> On Tue, Jul 09, 2019 at 10:09:16PM +0000, Gary R Hook wrote:
>> On 7/9/19 3:10 PM, Eric Biggers wrote:
>>> On Mon, Jul 08, 2019 at 05:08:09PM +0000, Gary R Hook wrote:
>>>> On 7/5/19 2:40 PM, Eric Biggers wrote:
>>>>> Hi Gary,
>>>>>
>>>>> On Wed, Jul 03, 2019 at 07:21:26PM +0000, Hook, Gary wrote:
>>>>>> The AES GCM function reuses an 'op' data structure, which members
>>>>>> contain values that must be cleared for each (re)use.
>>>>>>
>>>>>> Fixes: 36cf515b9bbe ("crypto: ccp - Enable support for AES GCM on v5 CCPs")
>>>>>>
>>>>>> Signed-off-by: Gary R Hook <[email protected]>
>>>>>> ---
>>>>>> drivers/crypto/ccp/ccp-ops.c | 12 +++++++++++-
>>>>>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>>>>
>>>>> Is this patch meant to fix the gcm-aes-ccp self-tests failure?
>>>>
>>>> Yessir, that is the intention. Apologies for not clarifying that point.
>>>>
>>>> grh
>>>
>>> Okay, it would be helpful if you'd explain that in the commit message.
>>
>> Gah. Of course. I'll repost.
>>
>>> Also, what branch does this patch apply to? It doesn't apply to cryptodev.
>>
>> I have endeavored to make a "git pull" and a full build a required,
>> regular part of my submission process, having made (plenty of) mistakes
>> in the past. I did so last week before posting this, and the patch
>> applied then, and applies now in my local copy, before and after a git
>> pull today.
>>
>> We've been having trouble with our SMTP mail server, and patches have
>> been going out base64 encoded. I'm willing to bet that's what you're
>> wrestling with.
>>
>> The last patch of mine that Herbert applied appeared to be encoded
>> thusly, but he was able to successfully apply it.
>>
>> I've been experimenting with changing the transfer encoding value
>> (charset=) to iso-8859-1 and us-ascii, but the best I can do is an
>> encoding that contains a lot of "=##" stuff. I'm not sure that's any
>> better, but my recent documentation patches contained those, and Herbert
>> was also able to apply them.
>>
>> We'd really like to know what Herbert does to accommodate these
>> non-textual emails? And is that something that others could do?
>>
>
> What I did was simply save your email and use 'git am -3' to try to apply it.
> It didn't work.
>
> Yes, your email is base64 encoded, which apparently 'git am' handles. But even
> after base64 decoding your patch has an extra blank line at the end, which
> corrupts it since it's part of the diff context.
I was unaware of this behavior. Thanks for letting me know.
> Can't you just use git send-email like everyone else?
Sure, until I find the time to fix stgit's email function.
It's still going to be quoted-printable text; I can't fix that problem
without the mail gateway cooperating. But I presume it will be in the
proper format. Look for a v2 and let me know how it comes out.
grh
On Tue, Jul 09, 2019 at 11:34:08PM +0000, Gary R Hook wrote:
> On 7/9/19 5:56 PM, Eric Biggers wrote:
> > On Tue, Jul 09, 2019 at 10:09:16PM +0000, Gary R Hook wrote:
> >> On 7/9/19 3:10 PM, Eric Biggers wrote:
> >>> On Mon, Jul 08, 2019 at 05:08:09PM +0000, Gary R Hook wrote:
> >>>> On 7/5/19 2:40 PM, Eric Biggers wrote:
> >>>>> Hi Gary,
> >>>>>
> >>>>> On Wed, Jul 03, 2019 at 07:21:26PM +0000, Hook, Gary wrote:
> >>>>>> The AES GCM function reuses an 'op' data structure, which members
> >>>>>> contain values that must be cleared for each (re)use.
> >>>>>>
> >>>>>> Fixes: 36cf515b9bbe ("crypto: ccp - Enable support for AES GCM on v5 CCPs")
> >>>>>>
> >>>>>> Signed-off-by: Gary R Hook <[email protected]>
> >>>>>> ---
> >>>>>> drivers/crypto/ccp/ccp-ops.c | 12 +++++++++++-
> >>>>>> 1 file changed, 11 insertions(+), 1 deletion(-)
> >>>>>
> >>>>> Is this patch meant to fix the gcm-aes-ccp self-tests failure?
> >>>>
> >>>> Yessir, that is the intention. Apologies for not clarifying that point.
> >>>>
> >>>> grh
> >>>
> >>> Okay, it would be helpful if you'd explain that in the commit message.
> >>
> >> Gah. Of course. I'll repost.
> >>
> >>> Also, what branch does this patch apply to? It doesn't apply to cryptodev.
> >>
> >> I have endeavored to make a "git pull" and a full build a required,
> >> regular part of my submission process, having made (plenty of) mistakes
> >> in the past. I did so last week before posting this, and the patch
> >> applied then, and applies now in my local copy, before and after a git
> >> pull today.
> >>
> >> We've been having trouble with our SMTP mail server, and patches have
> >> been going out base64 encoded. I'm willing to bet that's what you're
> >> wrestling with.
> >>
> >> The last patch of mine that Herbert applied appeared to be encoded
> >> thusly, but he was able to successfully apply it.
> >>
> >> I've been experimenting with changing the transfer encoding value
> >> (charset=) to iso-8859-1 and us-ascii, but the best I can do is an
> >> encoding that contains a lot of "=##" stuff. I'm not sure that's any
> >> better, but my recent documentation patches contained those, and Herbert
> >> was also able to apply them.
> >>
> >> We'd really like to know what Herbert does to accommodate these
> >> non-textual emails? And is that something that others could do?
> >>
> >
> > What I did was simply save your email and use 'git am -3' to try to apply it.
> > It didn't work.
> >
> > Yes, your email is base64 encoded, which apparently 'git am' handles. But even
> > after base64 decoding your patch has an extra blank line at the end, which
> > corrupts it since it's part of the diff context.
>
> I was unaware of this behavior. Thanks for letting me know.
>
> > Can't you just use git send-email like everyone else?
>
> Sure, until I find the time to fix stgit's email function.
>
> It's still going to be quoted-printable text; I can't fix that problem
> without the mail gateway cooperating. But I presume it will be in the
> proper format. Look for a v2 and let me know how it comes out.
>
> grh
Yes the v2 patch applies.
- Eric