* [PATCH] crypto: ccp - memset structure fields to zero before reuse @ 2019-07-03 19:21 Hook, Gary 2019-07-05 19:40 ` Eric Biggers 0 siblings, 1 reply; 8+ messages in thread From: Hook, Gary @ 2019-07-03 19:21 UTC (permalink / raw) To: linux-crypto; +Cc: Lendacky, Thomas, herbert, davem 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 <gary.hook@amd.com> --- 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; ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] crypto: ccp - memset structure fields to zero before reuse 2019-07-03 19:21 [PATCH] crypto: ccp - memset structure fields to zero before reuse Hook, Gary @ 2019-07-05 19:40 ` Eric Biggers 2019-07-08 17:08 ` Gary R Hook 0 siblings, 1 reply; 8+ messages in thread From: Eric Biggers @ 2019-07-05 19:40 UTC (permalink / raw) To: Hook, Gary; +Cc: linux-crypto, Lendacky, Thomas, herbert, davem 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 <gary.hook@amd.com> > --- > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] crypto: ccp - memset structure fields to zero before reuse 2019-07-05 19:40 ` Eric Biggers @ 2019-07-08 17:08 ` Gary R Hook 2019-07-09 20:10 ` Eric Biggers 0 siblings, 1 reply; 8+ messages in thread From: Gary R Hook @ 2019-07-08 17:08 UTC (permalink / raw) To: Eric Biggers, Hook, Gary; +Cc: linux-crypto, Lendacky, Thomas, herbert, davem 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 <gary.hook@amd.com> >> --- >> 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] crypto: ccp - memset structure fields to zero before reuse 2019-07-08 17:08 ` Gary R Hook @ 2019-07-09 20:10 ` Eric Biggers 2019-07-09 22:09 ` Gary R Hook 0 siblings, 1 reply; 8+ messages in thread From: Eric Biggers @ 2019-07-09 20:10 UTC (permalink / raw) To: Gary R Hook; +Cc: Hook, Gary, linux-crypto, Lendacky, Thomas, herbert, davem 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 <gary.hook@amd.com> > >> --- > >> 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] crypto: ccp - memset structure fields to zero before reuse 2019-07-09 20:10 ` Eric Biggers @ 2019-07-09 22:09 ` Gary R Hook 2019-07-09 22:56 ` Eric Biggers 0 siblings, 1 reply; 8+ messages in thread From: Gary R Hook @ 2019-07-09 22:09 UTC (permalink / raw) To: Hook, Gary, linux-crypto, Lendacky, Thomas, herbert, davem 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 <gary.hook@amd.com> >>>> --- >>>> 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] crypto: ccp - memset structure fields to zero before reuse 2019-07-09 22:09 ` Gary R Hook @ 2019-07-09 22:56 ` Eric Biggers 2019-07-09 23:34 ` Gary R Hook 0 siblings, 1 reply; 8+ messages in thread From: Eric Biggers @ 2019-07-09 22:56 UTC (permalink / raw) To: Gary R Hook; +Cc: Hook, Gary, linux-crypto, Lendacky, Thomas, herbert, davem 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 <gary.hook@amd.com> > >>>> --- > >>>> 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] crypto: ccp - memset structure fields to zero before reuse 2019-07-09 22:56 ` Eric Biggers @ 2019-07-09 23:34 ` Gary R Hook 2019-07-10 1:47 ` Eric Biggers 0 siblings, 1 reply; 8+ messages in thread From: Gary R Hook @ 2019-07-09 23:34 UTC (permalink / raw) To: Hook, Gary, linux-crypto, Lendacky, Thomas, herbert, davem 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 <gary.hook@amd.com> >>>>>> --- >>>>>> 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] crypto: ccp - memset structure fields to zero before reuse 2019-07-09 23:34 ` Gary R Hook @ 2019-07-10 1:47 ` Eric Biggers 0 siblings, 0 replies; 8+ messages in thread From: Eric Biggers @ 2019-07-10 1:47 UTC (permalink / raw) To: Gary R Hook; +Cc: Hook, Gary, linux-crypto, Lendacky, Thomas, herbert, davem 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 <gary.hook@amd.com> > >>>>>> --- > >>>>>> 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-07-10 1:47 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-07-03 19:21 [PATCH] crypto: ccp - memset structure fields to zero before reuse Hook, Gary 2019-07-05 19:40 ` Eric Biggers 2019-07-08 17:08 ` Gary R Hook 2019-07-09 20:10 ` Eric Biggers 2019-07-09 22:09 ` Gary R Hook 2019-07-09 22:56 ` Eric Biggers 2019-07-09 23:34 ` Gary R Hook 2019-07-10 1:47 ` Eric Biggers
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.