Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1197169 > unrolled thread

Re: Revisit AF_BUS: is it a better way to implement KDBUS?

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Revisit AF_BUS: is it a better way to implement KDBUS? cee1 <fykcee1@gmail.com> - 2015-07-31 18:30 +0200
    Re: Revisit AF_BUS: is it a better way to implement KDBUS? cee1 <fykcee1@gmail.com> - 2015-08-01 04:10 +0200

#1197169 — Re: Revisit AF_BUS: is it a better way to implement KDBUS?

2015-07-31 2:12 GMT+08:00 Andy Lutomirski <luto@amacapital.net>:
>
> 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)



-- 
Regards,

- cee1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1197904

2015-08-01 5:15 GMT+08:00 Andy Lutomirski <luto@amacapital.net>:
> On Fri, Jul 31, 2015 at 9:25 AM, cee1 <fykcee1@gmail.com> wrote:
>> 2015-07-31 2:12 GMT+08:00 Andy Lutomirski <luto@amacapital.net>:
>>>
>>> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web