Re: problems with signing and new crypto code

Shirish Pargaonkar <[email protected]> Fri, 17 Jun 2011 08:58:40 -0500
Newsgroups gmane.linux.file-systems.cifs
Message-ID <[email protected]>
On Fri, Jun 17, 2011 at 8:06 AM, Jeff Layton <[email protected]> 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 <[email protected]>
> Date: =A0 Tue Apr 12 09:13:44 2011 -0400
>
> =A0 =A0cifs: don't allow mmap'ed pages to be dirtied while under writebac=
k (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 <[email protected]>
>

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 resulti=
ng
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