require_gcm_256 seems to be mandatory for storage accounts where AES-256-GCM is the only enabled encryption channel despite enable_gcm_256 being enabled

[tspearconquest]

What happened:
We have an Azure Storage account where the only enabled encryption channel is AES-256-GCM, which we attempted to mount on an AKS node running Ubuntu 24.04. According to the Azure docs, AKS with Ubuntu 22.04 (currently GA, while 24.04 is in preview), supports AES-256-GCM, however it seems that in order to take advantage of AES-256-GCM, the cifs module parameter require_gcm_256 must be set to 1 just after running modprobe, and the underlying node's /etc/modprobe.d/cifs.conf must be updated with options cifs require_gcm_256=1 before Azure Files CSI driver is able to make use of AES-256-GCM. Without doing the above, we found that we would get a mount permission denied with error 13 unless we allowed AES-128-GCM on the storage account itself.

This occurs despite the fact that the CIFS module parameter enable_gcm_256 is set to Y, which in theory should allow the CIFS client to negotiate AES-256-GCM without outright requiring it.

What you expected to happen:
The CIFS client should at least attempt AES-256-GCM and fall back to AES-128-GCM, without requiring the AKS nodes to enforce AES-256-GCM usage by the CIFS client. Perhaps this may be due to an upstream issue, and should instead be reported to the CIFS client developers, however I think that Azure Files CSI driver can still help in the mean time by 1) confirming if that's the case, and 2) providing documentation that makes it clear this is a requirement to connect with a storage account that has only AES-256-GCM enabled.

How to reproduce it:

1. Configure storage account channel encryption to only AES-256-GCM and configure an Azure Files share
2. Install azure files CSI driver on an AKS cluster
3. Attempt to mount the Azure Files share in a pod without enforcing AES-256-GCM on the underlying AKS node nor on the pod level
4. Observe failure to mount with error code 13
5. Either reconfigure the storage account channel encryption to allow AES-128-GCM, or reconfigure the AKS node to require AES-256-GCM as described above
6. Attempt to mount the Azure Files share in a pod again
7. Observe a successful mount

Anything else we need to know?:

Environment:

• CSI Driver version: 1.33.5
• Kubernetes version (use kubectl version): 1.33.3
• OS (e.g. from /etc/os-release): Ubuntu 24.04
• Kernel (e.g. uname -a): 6.8.0-1034-azure
• Install tools:
• Others:

[tspearconquest]

I was able to find a question from last year on StackOverflow where someone using a FreeNAS device also had this same error code and did not have the module parameter set. I responded to that question suggesting that the user try to set the parameter to see if it works for them. In case it does, I believe that would confirm that this is a bug in the CIFS mounter wherein it is not even attempting to use 256 bits when it should.

As such, I've opened a thread on the linux-cifs mailing list and will update if/when I hear something back.

[tspearconquest]

Some testing by the cifs/samba developers seems to indicate Azure is to blame here. Despite being configured with only AES-256-GCM on the share, it responds to the client during negotiation with AES-128-GCM. The client has this cipher preferred in order to provide the best performance when both are enabled and so it attempts to negotiate with that.

Since that cipher isn't actually allowed per the share configuration, the share then rejects the request. I've opened a case with Azure to attempt to get the documentation made more clear regarding this on their side.

This explains why you have to require AES-256-GCM on the client side -- doing so causes the client to ignore the built-in cipher order and attempt to negotiate AES-256-GCM with the share anyway.

I will leave this issue open in hopes that either of the following can be taken up:

1. Update the documentation to clarify the above; or
2. Add a parameter to the CSI driver (under PersistentVolume.spec.volumeAttributes, perhaps) that allows the user to choose to enforce a specific cipher. This would greatly simplify the process of configuring the higher encryption if the driver can use that parameter to then configure the cifs module, rather than requiring users to run a highly privileged separate daemonset that enforces the higher encryption on all nodes.