Re: [PATCH] crypto: ccp - memset structure fields to zero before reuse

[Eric Biggers <ebiggers@kernel.org>]

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