[PATCH][SMB3.1.1] Add defines for new signing context

[Tom Talpey]

Indeed yes, my point is that until/unless Microsoft indicates
the new signing context is committed to the protocol, it's
premature to bake it into Linux, or anywhere else. Speaking
from experience, things have been changed or removed at some
very late dates, in fact.

While I have the floor, and just a personal opinion, I feel
there is a huge and confusing proliferation of module options
and mount flags creeping into cifs.ko over time here. Is this
really a good idea?

Tom.

On 10/16/2020 2:11 AM, ronnie sahlberg wrote:
> Looks good, but I think Tom's point is we should not put this in
> upstream until the feature is officially launched.
> In  wireshark, we can add these things immediately since any capture
> files with these parameters will continue to exist forever.
> See wireshark still supports pre-RFS versions of iSCSI.
> But for cifs.ko we might want to wait sending to Linus until it is
> officially released in a consumer version of windows.
> 
> Lets just look at SMB2.PDF and all the bitfields/flags that specify a
> feature with description and then the comment that it is not used,
> clients should set it to 0 and servers must ignore the flag. Things
> can change until official release.
> 
> 
> 
> On Fri, Oct 16, 2020 at 3:50 PM Steve French via samba-technical
> <samba-technical at lists.samba.org> wrote:
>>
>> Here is a patch to add a module load parm that is turned off by
>> default to allow users to enable it for experimentation
>>
>> # ls /sys/module/cifs/parameters/
>> CIFSMaxBufSize    cifs_min_small           enable_oplocks
>> cifs_max_pending  disable_legacy_dialects  enable_signing_negcontext
>> cifs_min_rcv      enable_gcm_256           require_gcm_256
>>
>> # cat /sys/module/cifs/parameters/enable_signing_negcontext
>> N
>>
>> On Thu, Oct 15, 2020 at 11:50 PM Steve French <smfrench at gmail.com> wrote:
>>>
>>>> suggest wrapping this context and the integrity algs in some kind of conditional
>>>
>>> I have a couple patches to send the context (which I haven't merged
>>> yet, because, similar to what you suggested, I wanted to make sure
>>> they were disabled by default).
>>>
>>> Tentative plan was to have them disabled by default, and sending the
>>> new context can be enabled for testing by a module parameter (e.g.
>>> "echo 1 >  /sys/modules/cifs/parameters/enable_signing_context"  or
>>> some similar config variable name)
>>>
>>> On Thu, Oct 15, 2020 at 1:15 PM Tom Talpey <tom at talpey.com> wrote:
>>>>
>>>> On 10/12/2020 5:50 AM, Aurélien Aptel wrote:
>>>>> Patch LGTM
>>>>>
>>>>> Reviewed-by: Aurelien Aptel <aaptel at suse.com>
>>>>>
>>>>> Stefan Metzmacher via samba-technical <samba-technical at lists.samba.org>
>>>>>> This isn't in MS-SMB2 yet.
>>>>>>
>>>>>> Is this AES_128?
>>>>>
>>>>> This is returned in latest Windows Server Insider builds but it's not
>>>>> documented yet.
>>>>>
>>>>> https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewserver
>>>>>
>>>>> I've asked dochelp about it during the SDC plugfest and they gave me
>>>>> this:
>>>>>
>>>>>       The new ContextType is:
>>>>>       SMB2_SIGNING_CAPABILITIES 0x0008
>>>>>       The Data field contains a list of signing algorithms.
>>>>>       •    It adds a new negotiate context, which enables SMB to decouple signing algorithms from dialects. E.g. if both client and server supports it, a session may use HMAC-SHA256 with SMB 3.1.1.
>>>>>       •    It adds the AES-GMAC algorithm.
>>>>>
>>>>>       SigningAlgorithmCount (2 bytes): Count of signing algorithms
>>>>>       SigningAlgorithms (variable): An array of SigningAlgorithmCount 16-bit integer IDs specifying the supported signing algorithms.
>>>>>
>>>>>       The following IDs are assigned:
>>>>>       0 = HMAC-SHA256
>>>>>       1 = AES-CMAC
>>>>>       2 = AES-GMAC
>>>>>
>>>>>
>>>>> I've been CCed in a Microsoft email thread later on and it seems to be
>>>>> unclear why this was missed/wasn't documented. Maybe this is subject to
>>>>> change so take with a grain of salt.
>>>>
>>>> Just curious if you've heard back on this. Insider builds will sometimes
>>>> support things that don't make it to the release. Even Preview docs can
>>>> change. However, AES_GMAC has been on the radar since 2015 (*) so
>>>> perhaps the time has come!
>>>>
>>>> I'd suggest wrapping this context and the integrity algs in some kind of
>>>> conditional, in case this is delayed...
>>>>
>>>> Tom.
>>>>
>>>> (*) slide 29+
>>>> https://www.snia.org/sites/default/files/SDC15_presentations/smb/GregKramer_%20SMB_3-1-1_rev.pdf
>>>
>>>
>>>
>>> --
>>> Thanks,
>>>
>>> Steve
>>
>>
>>
>> --
>> Thanks,
>>
>> Steve
> 
>