mount.cifs fails to negotiate AES-256-GCM but works when enforced via sysfs or modprobe options

[Enzo Matsumiya]

On 10/21, Thomas Spear wrote:
>This sort-of makes sense as to why it's happening. I can understand
>some code so what I see here is:
>
>>  else if (enable_gcm_256) {
>>                   pneg_ctxt->DataLength = cpu_to_le16(8); /* Cipher Count + 3 ciphers */
>>                   pneg_ctxt->CipherCount = cpu_to_le16(3);
>>                   pneg_ctxt->Ciphers[0] = SMB2_ENCRYPTION_AES128_GCM;
>>                   pneg_ctxt->Ciphers[1] = SMB2_ENCRYPTION_AES256_GCM;
>>                   pneg_ctxt->Ciphers[2] = SMB2_ENCRYPTION_AES128_CCM;
>
>Here, AES-256-GCM is second to AES-128-GCM when enable_gcm_256 is
>true, but if AES-256-GCM is still present as one of the ciphers as per
>this snipped, and the server doesn't support AES-128-GCM, shouldn't it
>fall-forward to AES-256-GCM instead of causing an error?

That's correct.

But I also see it working fine against Windows Server 2022.

On server:
   > Set-SmbServerConfiguration -EncryptionCiphers "AES_256_GCM"

On client:
   # mount.cifs -o ...,seal //srv/test /mnt/test
   # cat /sys/module/cifs/parameters/require_gcm_256
   N
   # cat /sys/module/cifs/parameters/enable_gcm_256
   Y
   # grep Encryption /proc/fs/cifs/DebugData
   Encryption: Negotiated cipher (AES256-GCM)

> IOW, I'm
>wondering if there's an issue elsewhere that's preventing the
>AES-256-GCM cipher from being used and reordering would simply
>band-aid the issue.
>
>> so if the server supports AES-256-GCM, the only way to make cifs use it
>> is with 'require_gcm_256', unless you disable AES-128-GCM on the server
>> (as you have observed).
>
>Actually, the issue I'm observing is that _when_ we disable
>AES-128-GCM on the server (Azure Files), mount.cifs on the client is
>failing to mount the share completely _until_ I set require_gcm_256.

Azure sometimes responds with unexpected (sometimes even out of spec)
settings.

I'll setup an Azure Files instance to test this.


Cheers,

Enzo