linux-kernel - Re: [GIT PULL] ksmbd server fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAH2r5muxwEMA9JpE6ijSbZEByxRmtNSiwcXMbOz+Ojo8_APJUQ@mail.gmail.com>
Date:   Sun, 21 May 2023 14:03:20 -0500
From:   Steve French <smfrench@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Namjae Jeon <linkinjeon@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        CIFS <linux-cifs@...r.kernel.org>,
        samba-technical <samba-technical@...ts.samba.org>
Subject: Re: [GIT PULL] ksmbd server fixes

On Sun, May 21, 2023 at 1:06 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
<...>

> We talked about directory layout issues some time ago, and there's
> kind of beginnings of it, but it never happened, and the parts that
> *did* happen I'm not super-happy about. That "fs/smbfs_common/"
> subdirectory is just fairly ugly.
>
> Would you mind horribly to just bite the bullet, and rename things,
> and put it all under "smbfs". Something like
>
>     mkdir fs/smbfs
>     git mv fs/cifs fs/smbfs/client
>     git mv fs/ksmbd fs/smbfs/server
>     git mv fs/smbfs_common fs/smbfs/common
>
> plus the required Makefile editing to just make it all build right?
>
> And if you prefer just "fs/smb" over "fs/smbfs", that sounds fine to
> me too, but I guess this all really does just the filesystem part
> (rather than all the printing and whatever other stuff that smb also
> contains).

Should be easy to move and more intuitive, although I would prefer
that we use fs/smb or fs/smb3 as the directory name instead of
fs/smbfs (since that old filesystem fs/smbfs was removed in 2.6.27.
So reusing the fs/smbfs directory name could confuse people looking
at git logs).  I am fine with doing (and related Kconfig and trivial
include path changes):

     git mv fs/cifs fs/smb/client
     git mv fs/ksmbd fs/smb/server
     git mv fs/smbfs_common fs/smb/common

This also might be a good time to take another step toward
moving people away from the old, less secure, SMB1 ("cifs")
dialect by adding a second .ko file to the client (e.g. add
"smb3.ko" in fs/smb/client) which would have support for the old
SMB1/CIFS dialect removed. We would keep cifs.ko for
compatibility purposes (cifs.ko would still have its current
config options so would have SMB1/CIFS enabled by default
but smb3.ko would only support modern, more secure dialects
and also would be smaller than cifs.ko since it would build with
CIFS_ALLOW_INSECURE_LEGACY disabled). There is a
precedent for something somewhat similar to this e.g. the NFS
client has four kernel modules in the fs/nfs directory.  On a
somewhat related note - at the Storage Developer Conference
last fall there was an interesting set of discussions around splitting
out the RDMA mapping layer ("smbdirect") by removing RDMA
related code from ksmbd.ko and cifs.ko and creating an
"smbdirect.ko" module for various RDMA use cases (not just cifs.ko
and ksmbd but perhaps also could help some user space apps,
Samba etc. in the future) - this "smbdirect.ko" (RDMA mapping
layer) could also go in fs/smb/common in the future.

I would be happy to do the move (to fs/smb) of the directories and
update the config soon (seems reasonably low risk) - let me know if you
want me to send it this week or wait till 6.5-rc
--
Thanks,

Steve