From nobody Mon Jan 06 19:10:19 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YRkKB6Xf5z5k3PJ for ; Mon, 06 Jan 2025 19:10:22 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YRkKB5XTBz4NvM; Mon, 6 Jan 2025 19:10:22 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1736190622; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=stn/jWpuVKLSgrG70xs0Q9/bqOKURngOuYjlVvWjjb8=; b=j7q5NUoVLxNskRd/4p9HtMURmk4v1e0UZNWI3BxmEyslWqn6rvH9Powm6BPkCrjYX2glfQ sEhx3h8xGKTB69U2Rvp0eie6Tqnm5Sw/4P619jdqYSono8b0F4K4xdayvp6mCFi9VC0oGt Na4XzwLR3kGeZArjT0rEUCpYdFzr5B6AiAoPTmLoAEnI2HsbGMNPWmuKRP3fFNUOToIVTj pK0Wabi3AyqyKBD/3FZSiBvCaqOWPybb51jD4aP4ConTwrtva0jB7LqYdpnP6tum8G8r9Q 8wfI9f42RsjQVJ4Sidk1mEzwpiPjNBKNYOfxBJZKRDTDY0XMDlKjX00L4w/Y4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1736190622; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=stn/jWpuVKLSgrG70xs0Q9/bqOKURngOuYjlVvWjjb8=; b=iNkS3xPonLAwDsoin2waUL9CxQsN/jbZNBxUYt+CI4yod1TbVfjQjZsd1Lf2zOudNgJryR tUZOXNUa/ai8QaTOs3ponD2j29POymi2JIzzGNf9/YESiSOA1CeTmtM0tOpgTDwemzOvlL /u5oRIIAWuK2zTBshWGJD4KuIUhlNalC3VWtiySSno1A7x1lFWAER8Q/Pi8e2/FvPWzwV3 wKQCWcjYNixaOHZ+NDfTOFeiXn4tmxkPLx+CpZs4PQb2Tqi2J2TBD6+KHc+8Ox21c4ofXJ MxRcckUm1x3q+oZ1qKGHrxElDbbisqoY6LIltf8bhPgFqTelMmXSoRNvEKzdxQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1736190622; a=rsa-sha256; cv=none; b=iR7ruuJOYhxWsYps5nc8DtlduEL9xFg8c0ehPIlEL8dmmAzDlBGYaB19VGp69Ty+7tTsv9 a5PXR+jjw21ti47CCFCqIOuGuIHa2+/G5OInkVt8k8mSgOTDOG6s2Qfk5WNFQPSEpvA/ww wPh1s9XdbDhwxW0X71a1h8nhW6RlRyKeHTcWuomJciTV1WIf9igUWr3EIrXpzY0dqMSeBO /ml1uaEgY9NdEwYmcI5X7wP/xpI1T1oHov+mqFFDHlahSbhuT/vYRLWWzNEOcCHzZCj5mj IFSh5W87KyuoLb8c9m5DSCBeEPVluiFrC9l9ot4acThH8Bd4zFbImAqnYQTocA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4YRkKB1qtZzpB0; Mon, 06 Jan 2025 19:10:22 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Mon, 6 Jan 2025 11:10:19 -0800 From: Gleb Smirnoff To: current@freebsd.org Cc: rmacklem@freebsd.org Subject: kernel RPC over netlink(4) and general krpc cleanup Message-ID: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, last year I tried to check-in a new implementation of unix(4) SOCK_STREAM and SOCK_SEQPACKET in d80a97def9a1, but was forced to back it out due to several kernel side abusers of a unix(4) socket. The most difficult ones are the NFS related RPC services, that act as RPC clients talking to an RPC servers in userland. Since it is impossible to fully emulate a userland process connection to a unix(4) socket they need to work with the socket internal structures bypassing all the normal KPIs and conventions. Of course they didn't tolerate the new implementation that totally eliminated intermediate buffer on the sending side. As I want to go forward with the new unix/stream and unix/seqpacket I need to do something with the kernel RPC. Today we got a new kind of socket - netlink(4) that is designed specifically for kernel<->userland communication. Although it is originally designed to provide kernel services to userland, we can work it around to do the opposite. The plan is that kernel modules that are seeking a specific RPC service will multicast their requests on specific netlink multicast groups and respective userland programs will reply on them. Working on that idea I realized that the kernel RPC code (living in sys/rpc) has quite a lot of dead code. Some is disabled at compile time, some is basically never called or never reached. Thus, in combination with two new modules: kernel netlink client and libc/rpc netlink server, I am also going to do some code deletion in sys/rpc. Note that I don't want to refactor anything, I just want to shave off pieces that are never used. This cleanup makes it much easier to understand what needs to be done to avoid abuse of unix(4) socket and what doesn't. My development branch is shared here: https://github.com/glebius/FreeBSD/commits/gss-netlink/ ATM, it has converted to netlink(4) communication for gssd(8) and rpcbind(8). Comments welcome! -- Gleb Smirnoff