[linux-cifs-client] problems with signing and new crypto code

[Shirish Pargaonkar]

On Fri, Jun 17, 2011 at 8:06 AM, Jeff Layton <jlayton at redhat.com> wrote:
> Hi Shirish,
>
> I've been working on some backports of some upstream patch series and
> have run into what I think is a problem with the new crypto code. The
> problem mainly seems to manifest itself as bad signatures in write
> calls. This causes a win2k8 server (at least) to reject the call with
> STATUS_ACCESS_DENIED and stop responding to other calls on the socket.
>
> I did a bisect of sorts, and got to this patch:
>
> commit ca83ce3d5b9ad321ee24f5870a77f0b21ac5a5de
> Author: Jeff Layton <jlayton at redhat.com>
> Date:   Tue Apr 12 09:13:44 2011 -0400
>
>    cifs: don't allow mmap'ed pages to be dirtied while under writeback (try #3)
>
> My original thought was that something was altering these pages while
> they were under writeback, but I did some instrumentation and found
> that not to be the case. The signature is the same before and after
> the send when this occurs. A key change in this patch is that when
> signing is enabled, the code started using CIFSSMBWrite2(), which
> marshals up the send buffer in an array of kvecs.
>
> That leads me to believe that the cifs_sign_smb2 codepath is busted.
>
> I'll see if I can come up with a testcase, but I'm not that familiar
> with the kernel crypto code. Is this something you've seen in your
> testing? Any immediate thoughts as to where the problem may be?
>
> --
> Jeff Layton <jlayton at redhat.com>
>

Jeff, no I have not seen this. You think some iozone testing against
a Windows server with the latest cifs code might expose this problem?
I will try both Windows 2003 server and Windows 2008 server.

cifs_sign_smb and cifs_sign_smb2 do the same exact thing except that
the messages that gets used in signature calculation are different in these
routines.

My initial thought was/is the same as yours, the content of message
used in calculating signature is different at the server and client resulting
in different signatures hence dropped smb connection by the server.
But it is possible cifs_sign_smb2 and/or cifs_calc_signature2 have a bug!

Regards,

Shirish