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