netdev - socket layer incorrectness

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: <1C8BCB3F488645A99B76E803ED3BD094@lzheng>
Date:	Mon, 1 Feb 2010 13:05:45 +0800
From:	"Lv Zheng" <lv.zheng@...iton.com.cn>
To:	<netdev@...r.kernel.org>
Subject: socket layer incorrectness

Hi, all

I'm new to this mailing list. Please forgive me if this mail is
interrupting you.

I read the kernel socket layer implementation recently.
Wondering whether one can kindly make some detailed explaination
for me, I sent this email to the netdev mailing list. 

==================================================

I noted BSD had presented socket API as follows:

socket(family, type, protocol)

Which means there should be sth. like:
sock_register_family
sock_register_type
sock_register_protocol
in the world.

As far as these abstractions are concerned, struct sock should be:
struct sock {
    struct family_ops *family_ops;
    struct sock_type_ops *type_ops;
    struct proto_ops *proto_ops;
};

==================================================

A. family abstaction
For family, I think it looks like a protocol factory, and owns
create/release ops might be enough for family_ops just like current
kernel does.

B. type abstaction
For type, we have SOCK_STREAM, SOCK_DGRAM, SOCK_RAW
for INET:
1. SOCK_STREAM: buffer requeued orderly for the upper level
   protocol layer without lower level protocol's head/tail.
2. SOCK_DGRAM: buffer defrag/fraged aligning lower level
   protocol's content due to lower level's MTU without lower level
   protocol's head/tail.
3. SOCK_RAW: buffer is copied directly from lower level queue.
   If socket is implemented in this way, defrag/frag/streaming can go
   into the socket layer and we can involve hardware as much as it
   could to accelarate fragmentation and streaming.

But currently we do not have type abstraction in the Linux kernel.

C. protocol abstaction
For protocol, we have proto_register in the kernel, but it does not
affect sock_create. In the socket layer, only /proc/net/protocols is
affected by such registration, proto_ops is mostly a family specific
implementation.

proto_ops should not related to the socket operations which should
be type_ops' responsibility while current kernel takes proto_ops as
type_ops.

IMO, proto_ops should contain operations as head/tail analysis,
buffer ordering determination and so on.

==================================================

Can someone tell me why current Linux kernel is not implemented in
the way that BSD socket abstraction tells us to do?

Best regards/Lv Zheng
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html