ksmbd: AES-GMAC signing support?

ksmbd: AES-GMAC signing support?

[Michail Andreas Michalopoulos]

Hi Namjae,

ksmbd currently negotiates HMAC-SHA256 and AES-CMAC for SMB 3.1.1
signing, but not AES-GMAC (SIGNING_ALG_AES_GMAC is defined in
fs/smb/common/smb2pdu.h but unused), which is what Windows 11 and
Server 2022 clients prefer when it is offered.

Would you be interested in patches adding it? Roughly:

 - accept AES-GMAC in the SMB2_SIGNING_CAPABILITIES negotiate context,
 - sign and verify with gcm(aes) over the message, using the nonce
   from MS-SMB2 3.1.4.1 (MessageId plus the request/response and
   CANCEL bits), and
 - keep HMAC-SHA256/AES-CMAC behaviour unchanged.

I would test it with smbtorture's signing tests and the ksmbd CI
tests, and check the existing signing paths against an older Windows
server I have access to.

I have exams until mid-November, so I would start on it after that,
and as it is a bigger change it may take a few weeks. If someone
needs it sooner, I'm happy to leave it to them.

Before I start: is anyone already working on this, or is there
anything you would like done differently?

Thanks,
Michalis

Re: ksmbd: AES-GMAC signing support?

[Enzo Matsumiya]

Hi Michail,

On 10/23, Michail Andreas Michalopoulos wrote:
>Hi Namjae,
>
>ksmbd currently negotiates HMAC-SHA256 and AES-CMAC for SMB 3.1.1
>signing, but not AES-GMAC (SIGNING_ALG_AES_GMAC is defined in
>fs/smb/common/smb2pdu.h but unused), which is what Windows 11 and
>Server 2022 clients prefer when it is offered.
>
>Would you be interested in patches adding it? Roughly:
>
> - accept AES-GMAC in the SMB2_SIGNING_CAPABILITIES negotiate context,
> - sign and verify with gcm(aes) over the message, using the nonce
>   from MS-SMB2 3.1.4.1 (MessageId plus the request/response and
>   CANCEL bits), and
> - keep HMAC-SHA256/AES-CMAC behaviour unchanged.
>
>I would test it with smbtorture's signing tests and the ksmbd CI
>tests, and check the existing signing paths against an older Windows
>server I have access to.
>
>I have exams until mid-November, so I would start on it after that,
>and as it is a bigger change it may take a few weeks. If someone
>needs it sooner, I'm happy to leave it to them.
>
>Before I start: is anyone already working on this, or is there
>anything you would like done differently?

I did this 4 years ago for cifs:

https://github.com/smfrench/smb3-kernel/commits/aes-gmac-v3/

I never sent the patches because my tests [0] showed that AES-CMAC was
slightly faster for cifs case.

After talking to Steve about it, our conclusion back then was that such
non-negligible overhead wasn't really worth the code change [1].

Feel free to use that code as a reference for your implementation.

I could certainly have gotten something wrong, but I didn't (don't)
really have the time to work on it again.


Cheers,

Enzo


[0] my tests were done with a user POV in mind, so everything was
measured in workload time rather than us/ms tracing.  Tested only
on common desktop HW too.

[1] AES-CMAC uses the shash crypto API, but AES-GMAC uses AEAD
encryption API (to only sign a payload you use an empty plaintext
buffer, and set the full payload to the associated data buffer).

This makes it require non-trivial changes other than simply loading
another shash alg.

Re: ksmbd: AES-GMAC signing support?

[Tom Talpey]

On 10/23/2026 2:24 PM, Enzo Matsumiya wrote:
> Hi Michail,
> 
> On 10/23, Michail Andreas Michalopoulos wrote:
>> Hi Namjae,
>>
>> ksmbd currently negotiates HMAC-SHA256 and AES-CMAC for SMB 3.1.1
>> signing, but not AES-GMAC (SIGNING_ALG_AES_GMAC is defined in
>> fs/smb/common/smb2pdu.h but unused), which is what Windows 11 and
>> Server 2022 clients prefer when it is offered.
>>
>> Would you be interested in patches adding it? Roughly:
>>
>> - accept AES-GMAC in the SMB2_SIGNING_CAPABILITIES negotiate context,
>> - sign and verify with gcm(aes) over the message, using the nonce
>>   from MS-SMB2 3.1.4.1 (MessageId plus the request/response and
>>   CANCEL bits), and
>> - keep HMAC-SHA256/AES-CMAC behaviour unchanged.
>>
>> I would test it with smbtorture's signing tests and the ksmbd CI
>> tests, and check the existing signing paths against an older Windows
>> server I have access to.
>>
>> I have exams until mid-November, so I would start on it after that,
>> and as it is a bigger change it may take a few weeks. If someone
>> needs it sooner, I'm happy to leave it to them.
>>
>> Before I start: is anyone already working on this, or is there
>> anything you would like done differently?
> 
> I did this 4 years ago for cifs:
> 
> https://github.com/smfrench/smb3-kernel/commits/aes-gmac-v3/
> 
> I never sent the patches because my tests [0] showed that AES-CMAC was
> slightly faster for cifs case.
> 
> After talking to Steve about it, our conclusion back then was that such
> non-negligible overhead wasn't really worth the code change [1].

I remember this discussion, and wonder if things may have changed.
Windows certainly prefers GMAC, and refreshing the numbers for Linux
(especially on ARM64) should be part of the discussion.

Personally I'd love to see this work, if for no other reason that
it's not about the local benefit, it's about requiring the peer to
implement something that it may not consider optimal. Choice is good.

Tom.

> Feel free to use that code as a reference for your implementation.
> 
> I could certainly have gotten something wrong, but I didn't (don't)
> really have the time to work on it again.
> 
> 
> Cheers,
> 
> Enzo
> 
> 
> [0] my tests were done with a user POV in mind, so everything was
> measured in workload time rather than us/ms tracing.  Tested only
> on common desktop HW too.
> 
> [1] AES-CMAC uses the shash crypto API, but AES-GMAC uses AEAD
> encryption API (to only sign a payload you use an empty plaintext
> buffer, and set the full payload to the associated data buffer).
> 
> This makes it require non-trivial changes other than simply loading
> another shash alg.
> 

Re: ksmbd: AES-GMAC signing support?

[mixalhs]

Hi Enzo, Tom,

On Fri, Oct 23, 2026, Enzo Matsumiya wrote:
> I did this 4 years ago for cifs:
>
> https://github.com/smfrench/smb3-kernel/commits/aes-gmac-v3/
> ...
> Feel free to use that code as a reference for your implementation.

Thanks, that's very helpful, and thanks for the quick replies. ksmbd
already sets up gcm(aes) AEAD transforms for encryption, so the server
side should be able to reuse most of that. Your branch will save me a
lot of time, and I'll credit you wherever I build on it.

On Fri, Oct 23, 2026, Tom Talpey wrote:
> refreshing the numbers for Linux (especially on ARM64) should be part
> of the discussion.

Agreed. I'll measure GMAC against CMAC signing on x86_64 and arm64 and
include the numbers with the patches, which as mentioned will be after
mid-November. Finally have a use for my arm64 machine hehe.

Thanks to you both!

Michalis

Re: ksmbd: AES-GMAC signing support?

[Namjae Jeon]

On Sat, Oct 24, 2026 at 7:36 AM mixalhs <mike.michalo@gmail.com> wrote:
Hi Michalis,

>
> Hi Enzo, Tom,
>
> On Fri, Oct 23, 2026, Enzo Matsumiya wrote:
> > I did this 4 years ago for cifs:
> >
> > https://github.com/smfrench/smb3-kernel/commits/aes-gmac-v3/
> > ...
> > Feel free to use that code as a reference for your implementation.
>
> Thanks, that's very helpful, and thanks for the quick replies. ksmbd
> already sets up gcm(aes) AEAD transforms for encryption, so the server
> side should be able to reuse most of that. Your branch will save me a
> lot of time, and I'll credit you wherever I build on it.
>
> On Fri, Oct 23, 2026, Tom Talpey wrote:
> > refreshing the numbers for Linux (especially on ARM64) should be part
> > of the discussion.
>
> Agreed. I'll measure GMAC against CMAC signing on x86_64 and arm64 and
> include the numbers with the patches, which as mentioned will be after
> mid-November. Finally have a use for my arm64 machine hehe.
GMAC signing support has been on my TODO list for quite a while. No
one else is currently working on this for ksmbd, so I really
appreciate you taking this on! When you submit the patches, could you
also update the KSMBD Feature Status table in
Documentation/filesystems/smb/ksmbd.rst? The “SMB3.1.1 GMAC signing
support” entry is currently marked as “Planned for future."

Re: ksmbd: AES-GMAC signing support?

[mixalhs]

Hi Namjae, all,

A quick follow-up with some early numbers, and a few questions I'd
like your opinion on before I send the series after mid-November.
Cc'ing Enzo and Tom since they asked for numbers, and the ksmbd
reviewers. There are three parts below: the patches, a speed
experiment in lib/crypto, and the benchmarks.

The series (2 patches, on ksmbd-for-next):
 1. ksmbd currently overwrites the algorithm picked from the client's
    SMB2_SIGNING_CAPABILITIES with AES-CMAC in init_smb3_11_server(),
    so a client that doesn't offer AES-CMAC (e.g. HMAC-SHA256 or
    AES-GMAC only) is answered with AES-CMAC and fails to connect.
    Patch 1 fixes that and keeps each signing key paired with its
    algorithm (session vs. channel keys for multichannel binding).
 2. AES-GMAC signing using the AES-GCM library API, plus the binding
    checks smbtorture expects for mixed GMAC/non-GMAC channels, and
    the feature table update.

The patches aren't posted yet; I'm happy to share them, and the
experiment, earlier if you'd like to look at the code first.

Tested with smbtorture 4.19 and 4.23 (each algorithm forced) and the
macOS 26 SMB client, which offers AES-GMAC first: 256 MiB copy with
signing required and encryption disabled, read back identical. I
haven't tested a Windows client yet.

Numbers on arm64 (Apple M4, Linux VM).

Signing only, 1 MiB message, median of 3 runs:

                    HMAC-SHA256  AES-CMAC   AES-GMAC
  library today      3160 MB/s  2750 MB/s    990 MB/s

So on arm64 GMAC is currently the slowest. The cause is in lib/crypto,
not ksmbd: the arm64 GHASH library code processes bulk data with the
NEON fallback, not PMULL (the migration commit says "though only with
NEON, not PMULL; for now the goal is just parity with crypto_shash").
As an experiment I computed GHASH through the existing 8-way PMULL
POLYVAL code with byte-reversed blocks (no new assembly; the lib/crypto
KUnit tests for GHASH, POLYVAL, AES-GCM and AES-CMAC pass under QEMU
and natively on the M4):

                    HMAC-SHA256  AES-CMAC   AES-GMAC
  with experiment    3150 MB/s  2740 MB/s  12230 MB/s

CMAC and HMAC use the unmodified library code in both tables. They
are inherently serial (each block depends on the previous one), while
GHASH can process 8 blocks in parallel.

End to end with smbtorture smb2.bench.read, signing required,
loopback, median of 6 runs of 5 s:

                     HMAC-SHA256  AES-CMAC   AES-GMAC
  1M reads, today     1354 MB/s   924 MB/s    797 MB/s
  1M reads, exp       1355 MB/s   930 MB/s   3370 MB/s
  4K reads/s, today       22330      21540      21100
  4K reads/s, exp         22650      21650      23700

These end-to-end numbers don't include the key-caching follow-up
(question 3); only the library change differs between the rows.
Small requests (smb2.bench.echo) are the same for all three. The same
approach on x86 (the kernel's PCLMUL code in a userspace harness,
Xeon) is about 3.8x faster than today's x86 GHASH (1.7 -> 6.5 GB/s).
Full numbers and methods are at the end.

Questions:
 1. Is the series OK to send as-is, given GMAC is slower on arm64
    until the library improves? ksmbd uses the client's first choice,
    and Windows and macOS put GMAC first.
 2. Would you mind if I raise the GHASH speedup with Eric Biggers on
    linux-crypto? It's outside ksmbd, so I wanted to check with you
    first.
 3. I also have a follow-up that prepares signing keys once per
    session/channel instead of per message (in a microbenchmark of
    ksmbd's signing path, AES-CMAC on 64-byte messages drops from
    about 125 to 32 ns on the M4). Should I send that later on its
    own, or as part of this series?

Full numbers, for reference:

arm64: Apple M4, Linux 7.3 VM (Lima, Apple Virtualization),
8 vCPUs, ksmbd-for-next + the 2 patches. "today" = unmodified
lib/crypto, "exp" = with the GHASH experiment.

Summary for AES-GMAC (details below; "cached" = key prepared once):

                       GMAC today   GMAC exp   speedup   vs CMAC (exp)
  sign 64 B, cached        108 ns      57 ns      1.9x   0.6x (slower)
  sign 64 B, per-msg       192 ns     234 ns      0.8x   0.5x (slower)
  sign 256 B, cached       395 ns      68 ns      5.8x   1.5x faster
  sign 4 KiB, cached      5608 ns     435 ns     12.9x   4.6x faster
  sign 1 MiB, cached     993 MB/s 12227 MB/s     12.3x   4.5x faster
  1M reads (smbtorture)  797 MB/s  3370 MB/s      4.2x   3.6x faster

Signing microbenchmark: a module that signs exactly like
ksmbd_sign_smb3_pdu(), with the key prepared per message (as ksmbd
does now) or once ("cached"). Median of 3 runs, ns per message:

  64 bytes            HMAC-SHA256   AES-CMAC   AES-GMAC
  per-msg key, today          125        120        192
  per-msg key, exp            122        126        234
  cached key,  today           89         32        108
  cached key,  exp             78         33         57

  256 bytes           HMAC-SHA256   AES-CMAC   AES-GMAC
  per-msg key, today          190        184        495
  per-msg key, exp            188        190        240
  cached key,  today          155         87        395
  cached key,  exp            140         99         68

  4 KiB               HMAC-SHA256   AES-CMAC   AES-GMAC
  per-msg key, today         1842       2083       5756
  per-msg key, exp           1838       2091        643
  cached key,  today         1799       1981       5608
  cached key,  exp           1786       1983        435

  1 MiB, MB/s         HMAC-SHA256   AES-CMAC   AES-GMAC
  per-msg key, today         3152       2740        994
  per-msg key, exp           3153       2746      12202
  cached key,  today         3159       2753        993
  cached key,  exp           3149       2739      12227

The per-message GMAC cost at 64 bytes goes up with the experiment
because preparing a GHASH key now also computes H^2..H^8; preparing
keys once (question 3) removes that.

The kernel's own KUnit benchmarks on the M4 with the experiment
Show the same picture, in MB/s:

  bytes      GHASH   POLYVAL   AES-CMAC
  256         8255     12895       2407
  4096       11047     14028       1507
  16384      11145     13718       1524

Workload: smbtorture 4.23.6 smb2.bench (nprocs=2, qdepth=4), client
and server in the same VM over loopback, SMB 3.1.1, signing required,
encryption off. Median of 6 runs of 5 s each:

                      HMAC-SHA256   AES-CMAC   AES-GMAC
  echo ops/s,  today        27673      27433      27583
  echo ops/s,  exp          27861      27900      28002
  4K reads/s,  today        22330      21537      21097
  4K reads/s,  exp          22650      21650      23700
  1M MB/s,     today         1354        924        797
  1M MB/s,     exp           1355        930       3370

x86: the kernel's x86 GHASH and POLYVAL assembly built into a
userspace harness, Intel Xeon @ 2.1 GHz (PCLMULQDQ + AVX). GHASH only
(no AES, no CMAC/HMAC comparison), best of 5, MB/s:

  bytes          GHASH today   via 8-way POLYVAL   speedup
  64                    1664                3519      2.1x
  4096                  1772                6674      3.8x
  1048576               1700                6472      3.8x

The GHASH-via-POLYVAL result matched the real GHASH output bit for bit
for every block count from 1 to 300 and for 1 MiB.

Disclosure: I used an AI assistant for the experiment. 
My background is in electrical engineering, and I have
some familiarity with crypto from security as a hobby, but I'm not
yet familiar with the kernel's crypto library code; the
experiment is only meant to show whether there is a gain, and if you
think it's worth pursuing I'd be very happy to rework it properly
myself.I ran the arm64 numbers, the native KUnit run and the macOS
test on my M4. The x86 harness, the KUnit run under QEMU and the
smbtorture 4.19 runs (UML) were run by the assistant in its own
environment, and I've reviewed those results; I don't have an x86
machine at hand right now. I'll also run the tests on a server with
two Intel Xeons soon; for now I'd mainly like your opinion on how to
approach this.

Thanks,
Michalis

Re: ksmbd: AES-GMAC signing support?

[mixalhs]

Hi all,

A short addition for question 1: x86 numbers and a Windows test.

Setup: 2 cloud VMs (AMD EPYC Milan, 4 vCPUs), 3.56 Gbit/s network,
ksmbd-for-next + the 2 patches.

Windows Server 2025 offered GMAC first and ksmbd answered AES-GMAC;
a 1 GiB copy to and from the share came back identical.

On x86 the slow part of the library is CBC-MAC, not GHASH:
aes_cbcmac_blocks() has an arch hook only on arm64, so x86 takes
the FPU for every 16-byte block. Signing 1 MiB, MB/s:

                    HMAC-SHA256   AES-CMAC      AES-GMAC
  library today            1494        207                  1174
  with experiment       1670      757 (3.7x)          2475 (2.1x)

(experiment: the arm64 GHASH approach ported to x86, plus one FPU
section per 4 KiB in CBC-MAC; lib/crypto KUnit tests pass.)

End to end, 1M reads: HMAC 449, CMAC 341, GMAC 469 MB/s today
(HMAC and GMAC at the network limit); CMAC 400 with the experiment.


Thanks,
Michalis

Re: ksmbd: AES-GMAC signing support?

[Namjae Jeon]

Hi Michalis,

> Questions:
>  1. Is the series OK to send as-is, given GMAC is slower on arm64
>     until the library improves? ksmbd uses the client's first choice,
>     and Windows and macOS put GMAC first.
Yes, please send the signing negotiation fix and AES-GMAC support
patches for review. It would be good to include test results with a
Windows client when you post the series.

>  2. Would you mind if I raise the GHASH speedup with Eric Biggers on
>     linux-crypto? It's outside ksmbd, so I wanted to check with you
>     first.
No, You can raise the GHASH optimization with Eric on linux-crypto.
The results look promising, and reusing the existing POLYVAL
implementation seems worth exploring. If you could also send a patch
series for this work, it could be reviewed independently of the ksmbd
series.

>  3. I also have a follow-up that prepares signing keys once per
>     session/channel instead of per message (in a microbenchmark of
>     ksmbd's signing path, AES-CMAC on 64-byte messages drops from
>     about 125 to 32 ns on the M4). Should I send that later on its
>     own, or as part of this series?
I'd prefer the key-caching change as a separate follow-up series. It
benefits the existing algorithms as well, and keeping it separate will
make review and performance comparisons easier.
Thanks!

Re: ksmbd: AES-GMAC signing support?

[Namjae Jeon]

On Sun, Oct 25, 2026 at 1:14 AM mixalhs <mike.michalo@gmail.com> wrote:
>
> Hi all,
>
> A short addition for question 1: x86 numbers and a Windows test.
>
> Setup: 2 cloud VMs (AMD EPYC Milan, 4 vCPUs), 3.56 Gbit/s network,
> ksmbd-for-next + the 2 patches.
>
> Windows Server 2025 offered GMAC first and ksmbd answered AES-GMAC;
> a 1 GiB copy to and from the share came back identical.
>
> On x86 the slow part of the library is CBC-MAC, not GHASH:
> aes_cbcmac_blocks() has an arch hook only on arm64, so x86 takes
> the FPU for every 16-byte block. Signing 1 MiB, MB/s:
>
>                     HMAC-SHA256   AES-CMAC      AES-GMAC
>   library today            1494        207                  1174
>   with experiment       1670      757 (3.7x)          2475 (2.1x)
>
> (experiment: the arm64 GHASH approach ported to x86, plus one FPU
> section per 4 KiB in CBC-MAC; lib/crypto KUnit tests pass.)
>
> End to end, 1M reads: HMAC 449, CMAC 341, GMAC 469 MB/s today
> (HMAC and GMAC at the network limit); CMAC 400 with the experiment.
Thanks for the update. The results look promising. I've answered your
questions in my earlier reply.