2015-08-01 5:15 GMT+08:00 Andy Lutomirski <[email protected]>: > On Fri, Jul 31, 2015 at 9:25 AM, cee1 <[email protected]> wrote: >> 2015-07-31 2:12 GMT+08:00 Andy Lutomirski <[email protected]>: >>> >>> I find myself wondering whether an in-kernel *bus* is a good idea at >>> all. Creating a bus that unprivileged programs are allowed to >>> broadcast on (which is kind of the point) opens up big cans of worms. >> >> This can be solved in this AF_BUS like this: >> * Becoming a bus master needs a proper CAP. >> * Impose a bus endpoint to join multicast address "maddr1" first, if >> it wants to send to multicast address "maddr2". >> >> The bus endpoint sends the request of joining maddr1, and the bus >> master grants it with replying a cmsg(control message) and setting up >> a proper eBPF. >> >> Next time, the bus endpoint sends to maddr2, the kernel will allow this if: >> 1) maddr1 & maddr2 == maddr1 >> And 2) the eBPF allows it. >> (i.e. the same multicast match logic in this AF_BUS) >> > > I don't understand. > > If the endpoint is unprivileged (i.e. random untrusted things can send > multicast), then you have the scaling problem. If the endpoint is > privileged, then it's much less clear to me that this thing is useful.
That means an endpoint has to request the ability of sending to a specific multicast address(aka join a multicast group), and it's up to bus master whether grants it or not. -- Regards, - cee1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
