CIFSD

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
CIFSD
Original author(s)Namjae Jeon
Developer(s)Namjae Jeon, Sergey Senozhatsky, Hyunchul Lee
Repositorygithub.com/cifsd-team
Written inC
Operating systemLinux
TypeNetwork Filesystem
LicenseGPLv2

CIFSD is an open-source in-kernel CIFS/SMB server created by Namjae Jeon for the Linux kernel. Initially the goal is to provide improved file I/O performance, but the bigger goal is to have some new features which are much easier to develop and maintain inside the kernel and expose the layers fully. Directions can be attributed to sections where Samba is moving to few modules inside the kernel to have features like Remote direct memory access (RDMA) to work with actual performance gain.

Features[edit]

Implemented[edit]

  • SMB1(CIFS), SMB2/3 protocols for basic file sharing
  • Compound requests
  • oplock/lease
  • Large MTU(Multi-credit)
  • NTLM/NTLMv2
  • Auto negotiation
  • HMAC-SHA256 Signing
  • Secure negotiate
  • Signing Update
  • Pre-authentication integrity(SMB 3.1.1, Windows 10)
  • SMB encryption (CCM, GCM)
  • SMB direct(RDMA)
  • WinACL (Security descriptor)
  • Kerberos

Planned[edit]

  • Multi-channel
  • Durable handle and v2
  • Persistent handles
  • Directory lease
  • Cluster Support
  • SCSI over SMB3

Architecture[edit]

The subset of performance related operations belong in kernelspace and the other subset which belong to operations which are not really related with performance in userspace. So, DCE/RPC management that has historically resulted into number of buffer overflow issues and dangerous security bugs and winreg and user account management are implemented in user space as ksmbd.mountd. File operations that are related with performance (open/read/write/close etc.) in kernel space (ksmbd). This also allows for easier integration with VFS interface for all file operations.

Cifsd architecture.png

ksmbd (kernel daemon)[edit]

When the server daemon is started, It starts up a forker thread (ksmbd/0) at initialization time and open a dedicated port 445 for listening to SMB requests. Whenever new clients make request, forker thread will accept the client connection and fork a new thread for dedicated communication channel between the client and the server. It allows for parallel processing of SMB requests (commands) from clients as well as allowing for new clients to make new connections. Each instance is named ksmbd/1~n to indicate connected clients. Depending on the SMB request types, each new thread can decide to pass through the commands to the user space (ksmbd.mountd), currently DCE/RPC commands are identified to be handled through the user space.

To further utilize the linux kernel, it has been chosen to process the commands as default workitems and to be executed in the handlers of the default kworker threads. It allows for multiplexing of the handlers as the kernel take care of initiating extra worker threads if the load is increased and vice versa, if the load is decreased it destroys the extra worker threads. So, after connection is established with client. Dedicated ksmbd/1..n takes complete ownership of receiving/parsing of SMB commands. Each command received is worked in parallel i.e., there can be multiple clients commands which are worked in parallel. After receiving each command a separated kernel workitem is prepared for each command which is further queued to be handled by default kworker'threads inside the kernel. So, each SMB workitem is queued to the kworkers. This allows the benefit of load sharing to be managed optimally by the default kernel and optimizing client performance by handling client commands in parallel.

ksmbd.mountd (user space daemon)[edit]

ksmbd.mountd is userspace process to, transfer user account and password that are registered using ksmbd.adduser (part of utils for user space). Further it allows sharing information parameters that parsed from smb.conf to smb export layer in kernel. For the execution part it has a daemon which is continuously running and connected to the kernel interface using netlink socket, it waits for the requests (dcerpc and winreg). It handles RPC calls (at a minimum few dozen) that are most important for file server from NetShareEnum and NetServerGetInfo and various DFS related calls which a server must implement. Complete DCE/RPC response is prepared from the user space and passed over to the associated kernel thread for the client.

See also[edit]

References[edit]

External links[edit]