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
| ||
|
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
Powered by blists - more mailing lists