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  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]
Date:	Mon, 1 Feb 2010 13:05:45 +0800
From:	"Lv Zheng" <>
To:	<>
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:
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 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

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

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
More majordomo info at

Powered by blists - more mailing lists