netdev - Feature: "misc" pseudo protocol family

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>] [day] [month] [year] [list]

Message-ID: <903eed0a-b0c8-f351-cbc1-135ddaf3adcc@rosenau-ka.de>
Date:   Fri, 7 Feb 2020 07:59:43 +0100
From:   Martin Rosenau <martin@...enau-ka.de>
To:     netdev@...r.kernel.org
Subject: Feature: "misc" pseudo protocol family

Hello,

Unlike other OSs, Linux is often used to run experimental software. In 
my case it was an uncommon network protocol that I wanted to implement 
in a kernel module.

Unfortunately, it is not possible to add additional "AF_xxx" protocols 
to Linux without re-compiling the kernel because there are arrays with 
the size "AF_MAX" so Linux does not allow "AF_xxx" constants above "AF_MAX".

Simply increasing "AF_MAX" and leaving a range free for experimental 
protocols might be a solution; however, in this case the constants 
"AF_xxx" would have a different meaning on different computers, so 
programs using such protocols are not interchangable between computers.

To solve this, I'd like to propose a "protocol multiplexer" using 
string-based protocol IDs instead of integers intended for experimental 
or uncommon protocols:

Instead of doing:

   mySocket = socket(PF_INET3, SOCK_STREAM, IPPROTO_TCP);

... you would do:

   mySocket = socket(PF_MISC, SOCK_DGRAM, 0);

   protocolId = ioctl(mySocket, SIOCPFMISCQUERYNAME, "TCP_IPV3");

   close(mySocket);

   mySocket = socket(PF_MISC, SOCK_STREAM, protocolId);

A loadable kernel module implementing such a protocol would register 
itself using its string ID at the "PF_MISC" implementation instead of 
using "sock_register()" and an "AF_xxx" constant.

The actual PF_MISC implementation can be done in a kernel module; 
however, the change of the AF_MAX constant and the definition of PF_MISC 
has to be done in the kernel itself.

I'm new to kernel development, so I apologize if posting this message 
here was not a good idea.

I was already posting this proposal to the Linux kernel bugzilla; there 
I was told to post this idea to this mailing list.

Thanks for reading

Martin