Bug 8245 - signing issues in recent kernels
signing issues in recent kernels
Status: RESOLVED INVALID
Product: CifsVFS
Classification: Unclassified
Component: kernel fs
2.6
All Linux
: P5 normal
: ---
Assigned To: Jeff Layton
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-06-17 20:51 UTC by Jeff Layton
Modified: 2012-02-13 19:48 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Layton 2011-06-17 20:51:39 UTC
I'm seeing some issues with signing in recent kernels. The problem seems to have been introduced with the patches that switch cifs over to use the crypto APIs.

When I send large SMB's win2k8 seems to consistently fail the signature check. The threshold seems to be at 16705 byte SMBs. This corresponds to a WriteAndX of 16641 bytes. One byte less than that, and the signature check consistently passes.

I think that the reason we're just noticing this now is a confluence of changes:

1) Shirish's conversion to use the crypto APIs. This spans several patches and follow-on bugfixes.

2) commit ca83ce3d changed the code to always use "zero-copy" writes, even when signing is enabled, so signed connections now use larger SMBs

I first noticed this while backporting some patches from upstream, so I was able to do some experimentation. The older crypto code does not exhibit this problem, even when I turn on "zero-copy" writes.

To make this even more confusing, the new crypto code never seems to make samba fail. It passes those signature checks just fine.

Obviously more work is needed to box in this problem, but it seems like a clear regression in the crypto code. Why samba doesn't seem to care is thus far a mystery.
Comment 1 Jeff Layton 2011-06-18 10:35:32 UTC
cc'ing Jeremy in case he has any insight here...
Comment 2 Steve French 2011-06-18 13:35:43 UTC
No failure to samba (where debug easier)?
Comment 3 Jeff Layton 2011-06-20 13:46:16 UTC
Yep, this seems to be a "stealth" limitation in windows. The CAP_LARGE_READX/WRITEX bits are set, which should mean that the server can handle these larger frames. It doesn't seem to however.

I've sent a note to MS dochelp to get come clarification in the hopes that we can come up with a way to detect these problems automatically and deal with them.
Comment 4 Jeremy Allison 2011-06-20 21:43:43 UTC
Can you post a capture file from the fail ? I might be able to tell you what to use by looking at the early response packets from the win28k server.

Jeremy.
Comment 5 Jeff Layton 2011-06-21 10:47:46 UTC
Thanks Jeremy, but I think I've got this figured out. I posted a message to dochelp and cifs-protocol lists:

    http://lists.samba.org/archive/cifs-protocol/2011-June/001921.html

...George Colley and Hongwei Sun pointed out that this is expected behavior and that we should just ignore the CAP_LARGE_WRITEX bit when signing is enabled. I've got a patch that I'm testing now that should take this into account when the wsize is negotiated.
Comment 6 Jeff Layton 2012-02-13 19:48:50 UTC
Closing with a resolution of INVALID since it ended up being a misunderstanding about the limitations of windows writes with signing.