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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 02 Jun 2007 11:51:58 +0200 From: Oliver Hartkopp <oliver@...tkopp.net> To: Patrick McHardy <kaber@...sh.net>, Urs Thuermann <urs@...ogud.escape.de> CC: David Miller <davem@...emloft.net>, Thomas Gleixner <tglx@...utronix.de>, Oliver Hartkopp <oliver.hartkopp@...kswagen.de>, Urs Thuermann <urs.thuermann@...kswagen.de>, netdev@...r.kernel.org Subject: Re: [patch 5/7] CAN: Add virtual CAN netdevice driver Patrick McHardy wrote: > Oliver Hartkopp wrote: > >> Patrick McHardy wrote: >> > > Yes, its working, but only in certain combinations and you're breaking > the rules for skb->cb, making it impossible for other layers to use. > skb->sk is "stable" at the output path, the regular loopback device > orphans the skb in hard_start_xmit. So you can at least use it there. > > >> Would therefore skb->cb left unchanged in my skb's? Or is there any flag >> that can be set in the skb to keep the packet scheduler's hands off? >> > > > No, and I don't think we want a flag to signal that something is > violating the rules for skb->cb, there are other users of this > besides qdiscs. > Hm - regarding Patricks and Urs' last mails i just had the idea to put the sk-reference that's needed for this special CAN-only-loopback-functionality into the data section of the skb, e.g. by introducing a new struct can_skb_data: struct can_skb_data { struct can_frame cf; sock *txsk; }; So instead of allocating the space of struct can_frame the alloc_skb() would allocate the size of struct can_skb_data. The needed txsk would be stable in any case and could be used like the currently missused skb->cb. This would also lead to a type proof(!) implementation. In raw_rcv() in raw.c there could be a check for the size of struct can_skb_data first before checking the txsk - this would also guarantee the backward compatibility for current CAN drivers that allocate only the size of struct can_frame. For me this looks like a safe and compatible (Kernel & CAN) solution. Any objections/comments for this approach? Best regards, Oliver - 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