linux-cifs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Enzo Matsumiya <ematsumiya@suse.de>
Cc: linux-cifs@vger.kernel.org, Steve French <sfrench@samba.org>,
	samba-technical@lists.samba.org, linux-crypto@vger.kernel.org,
	linux-kernel@vger.kernel.org, Paulo Alcantara <pc@manguebit.org>,
	Ronnie Sahlberg <ronniesahlberg@gmail.com>,
	Shyam Prasad N <sprasad@microsoft.com>,
	Tom Talpey <tom@talpey.com>, Bharath SM <bharathsm@microsoft.com>
Subject: Re: [PATCH 0/8] smb: client: More crypto library conversions
Date: Mon, 13 Oct 2025 23:07:37 -0700	[thread overview]
Message-ID: <20251014060737.GD2763@sol> (raw)
In-Reply-To: <ihoaj3ymhuesevdb7k2kg2a2axdkishrrrjr2teigelhkxmt4s@do2n6pkdmaas>

On Mon, Oct 13, 2025 at 11:44:37AM -0300, Enzo Matsumiya wrote:
> Hi Eric,
> 
> On 10/11, Eric Biggers wrote:
> > This series converts fs/smb/client/ to access SHA-512, HMAC-SHA256, MD5,
> > and HMAC-MD5 using the library APIs instead of crypto_shash.
> > 
> > This simplifies the code significantly.  It also slightly improves
> > performance, as it eliminates unnecessary overhead.
> > 
> > Tested with Samba with all SMB versions, with mfsymlinks in the mount
> > options, 'server min protocol = NT1' and 'server signing = required' in
> > smb.conf, and doing a simple file data and symlink verification test.
> > That seems to cover all the modified code paths.
> > 
> > However, with SMB 1.0 I get "CIFS: VFS: SMB signature verification
> > returned error = -13", regardless of whether this series is applied or
> > not.  Presumably, testing that case requires some other setting I
> > couldn't find.
> > 
> > Regardless, these are straightforward conversions and all the actual
> > crypto is exactly the same as before, as far as I can tell.
> 
> I think the overall series looks good and do a great cleanup.
> 
> Just a minor nit about fips_enabled: since it's now being handled
> explicitly (rather than an error on cifs_alloc_hash() currently), I
> think it makes sense to move the check to mount code path when
> 'sectype == NTLMv2' (I don't particularly care about SMB1, but
> something similar can be done for 'smb1 && sign' cases I guess).

For MD5 message signing and NTLMv2, this series keeps the fips_enabled
checks where they were before.  That is, they're inserted where the
calls to cifs_alloc_hash() were before.  I think moving them to earlier
locations is best done in later patches, as it's not obvious (at least
to me) exactly how to do that.

I spent a while reading the code again, and this is what I came up with:

- For MD5 message signing: cifs_enable_signing() is probably the right
  place to disallow it.  However, it's called regardless of the signing
  algorithm.  So it needs a parameter passed in that tells it that the
  signing algorithm will be MD5 (or equivalently the dialect is SMB1).

- For NTLMv2: select_sec() and SMB2_select_sec() are where the
  authentication protocol is selected and are probably the right places
  to disallow NTLMv2 and RawNTLMSSP.  However, those are two places, not
  one.  We'd have to remember to put the fips_enabled check in both.

The nice thing about keeping the fips_enabled checks next to the actual
uses of the algorithms is that it ensures they stay in sync.  So maybe
we should just stay with that here.

- Eric

  reply	other threads:[~2025-10-14  6:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-12  1:57 [PATCH 0/8] smb: client: More crypto library conversions Eric Biggers
2025-10-12  1:57 ` [PATCH 1/8] smb: client: Use SHA-512 library for SMB3.1.1 preauth hash Eric Biggers
2025-10-12  1:57 ` [PATCH 2/8] smb: client: Use HMAC-SHA256 library for key generation Eric Biggers
2025-10-12  1:57 ` [PATCH 3/8] smb: client: Use HMAC-SHA256 library for SMB2 signature calculation Eric Biggers
2025-10-12  1:57 ` [PATCH 4/8] smb: client: Use MD5 library for M-F symlink hashing Eric Biggers
2025-10-12  1:57 ` [PATCH 5/8] smb: client: Use MD5 library for SMB1 signature calculation Eric Biggers
2025-10-12  1:57 ` [PATCH 6/8] smb: client: Use HMAC-MD5 library for NTLMv2 Eric Biggers
2025-10-12  1:57 ` [PATCH 7/8] smb: client: Remove obsolete crypto_shash allocations Eric Biggers
2025-10-12  1:57 ` [PATCH 8/8] smb: client: Consolidate cmac(aes) shash allocation Eric Biggers
2025-10-13 14:44 ` [PATCH 0/8] smb: client: More crypto library conversions Enzo Matsumiya
2025-10-14  6:07   ` Eric Biggers [this message]
2025-10-14  3:42 ` Eric Biggers
2025-10-17 16:12   ` Steve French
2025-10-17 16:24     ` Eric Biggers
2025-10-14  7:55 ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251014060737.GD2763@sol \
    --to=ebiggers@kernel.org \
    --cc=bharathsm@microsoft.com \
    --cc=ematsumiya@suse.de \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pc@manguebit.org \
    --cc=ronniesahlberg@gmail.com \
    --cc=samba-technical@lists.samba.org \
    --cc=sfrench@samba.org \
    --cc=sprasad@microsoft.com \
    --cc=tom@talpey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).