On Wed, Oct 7, 2015 at 4:49 PM, Alexei Starovoitov wrote:
> On 10/7/15 3:22 PM, Kees Cook wrote:
>>>
>>> Yes, I agree with you that there would be a CVE regardless. I still
>>> >like the option of configurable access, not a big fan of the sysctl
>>> >either. Thinking out loudly, what about a Kconf
On 10/7/15 11:21 PM, Ingo Molnar wrote:
so I see no reason why unprivileged eBPF couldn't have a sysctl too - with the
default value set to permissive.
agreed. sent out v2 follows 'modules_disabled' style.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a mes
* Alexei Starovoitov wrote:
> As far as sysctl we can look at two with similar purpose:
> sysctl_perf_event_paranoid and modules_disabled.
> First one is indeed multi level, but not because of the fear of bugs,
> but because of real security implications.
It serves both purposes flexibly, and n
On 10/5/15 1:48 PM, Alexei Starovoitov wrote:
Unprivileged socket filter bpf programs have access to the
following helper functions:
- map lookup/update/delete (but they cannot store kernel pointers into them)
- get_random (it's already exposed to unprivileged user space)
- get_smp_processor_id
-
On 10/7/15 3:22 PM, Kees Cook wrote:
Yes, I agree with you that there would be a CVE regardless. I still
>like the option of configurable access, not a big fan of the sysctl
>either. Thinking out loudly, what about a Kconfig option? We started
>out like this on bpf(2) itself (initially under expe
On Wed, Oct 7, 2015 at 3:07 PM, Daniel Borkmann wrote:
> On 10/07/2015 11:20 PM, Alexei Starovoitov wrote:
>>
>> On 10/6/15 5:45 AM, Daniel Borkmann wrote:
>>>
>>> Should instead something similar be adapted on bpf(2) as well? Or, would
>>> that even be more painful for application developers ship
On 10/07/2015 11:20 PM, Alexei Starovoitov wrote:
On 10/6/15 5:45 AM, Daniel Borkmann wrote:
Should instead something similar be adapted on bpf(2) as well? Or, would
that even be more painful for application developers shipping their stuff
through distros in the end (where they might then decide
On 10/6/15 5:45 AM, Daniel Borkmann wrote:
Should instead something similar be adapted on bpf(2) as well? Or, would
that even be more painful for application developers shipping their stuff
through distros in the end (where they might then decide to just setup
everything BPF-related and then drop
* Andy Lutomirski wrote:
> On Tue, Oct 6, 2015 at 10:56 AM, Eric Dumazet wrote:
> > On Tue, 2015-10-06 at 10:50 -0700, Alexei Starovoitov wrote:
> >
> >> was also thinking that we can do it only in paths that actually
> >> have multiple protocol layers, since today bpf is mainly used with
> >>
On 10/6/15 10:56 AM, Eric Dumazet wrote:
On Tue, 2015-10-06 at 10:50 -0700, Alexei Starovoitov wrote:
was also thinking that we can do it only in paths that actually
have multiple protocol layers, since today bpf is mainly used with
tcpdump(raw_socket) and new af_packet fanout both have cb clea
On Tue, Oct 6, 2015 at 10:56 AM, Eric Dumazet wrote:
> On Tue, 2015-10-06 at 10:50 -0700, Alexei Starovoitov wrote:
>
>> was also thinking that we can do it only in paths that actually
>> have multiple protocol layers, since today bpf is mainly used with
>> tcpdump(raw_socket) and new af_packet fa
On 10/06/2015 07:50 PM, Alexei Starovoitov wrote:
On 10/6/15 1:39 AM, Daniel Borkmann wrote:
[...] Also classic BPF would then need to test for it, since a socket
filter
doesn't really know whether native eBPF is loaded there or a
classic-to-eBPF
transformed one, and classic never makes use of t
On Tue, 2015-10-06 at 10:50 -0700, Alexei Starovoitov wrote:
> was also thinking that we can do it only in paths that actually
> have multiple protocol layers, since today bpf is mainly used with
> tcpdump(raw_socket) and new af_packet fanout both have cb cleared
> on RX, because it just came out
On 10/6/15 1:39 AM, Daniel Borkmann wrote:
[...] Also classic BPF would then need to test for it, since a socket
filter
doesn't really know whether native eBPF is loaded there or a
classic-to-eBPF
transformed one, and classic never makes use of this. Anyway, it
could be done
by adding a bit flag
On 10/06/2015 02:51 AM, Alexei Starovoitov wrote:
On 10/5/15 3:14 PM, Daniel Borkmann wrote:
One scenario that comes to mind ... what happens when there are kernel
pointers stored in skb->cb[] (either from the current layer or an old
one from a different layer that the skb went through previousl
On 10/06/2015 10:20 AM, Ingo Molnar wrote:
* Daniel Borkmann wrote:
On 10/06/2015 09:13 AM, Ingo Molnar wrote:
* Alexei Starovoitov wrote:
On 10/5/15 3:14 PM, Daniel Borkmann wrote:
One scenario that comes to mind ... what happens when there are kernel
pointers stored in skb->cb[] (eith
* Daniel Borkmann wrote:
> On 10/06/2015 09:13 AM, Ingo Molnar wrote:
> >
> >* Alexei Starovoitov wrote:
> >
> >>On 10/5/15 3:14 PM, Daniel Borkmann wrote:
> >>>One scenario that comes to mind ... what happens when there are kernel
> >>>pointers stored in skb->cb[] (either from the current laye
On 10/06/2015 09:13 AM, Ingo Molnar wrote:
* Alexei Starovoitov wrote:
On 10/5/15 3:14 PM, Daniel Borkmann wrote:
One scenario that comes to mind ... what happens when there are kernel
pointers stored in skb->cb[] (either from the current layer or an old
one from a different layer that the s
* Alexei Starovoitov wrote:
> On 10/5/15 3:14 PM, Daniel Borkmann wrote:
> >One scenario that comes to mind ... what happens when there are kernel
> >pointers stored in skb->cb[] (either from the current layer or an old
> >one from a different layer that the skb went through previously, but
> >w
On 10/5/15 3:14 PM, Daniel Borkmann wrote:
One scenario that comes to mind ... what happens when there are kernel
pointers stored in skb->cb[] (either from the current layer or an old
one from a different layer that the skb went through previously, but
which did not get overwritten)?
Socket filt
On 10/5/15 3:02 PM, Kees Cook wrote:
the array maps that hold FDs (BPF_MAP_TYPE_PROG_ARRAY and
>BPF_MAP_TYPE_PERF_EVENT_ARRAY) don't have lookup/update accessors
>from the program side, so programs cannot see or manipulate
>those pointers.
>For the former only bpf_tail_call() is allowed that take
On 10/05/2015 10:48 PM, Alexei Starovoitov wrote:
In order to let unprivileged users load and execute eBPF programs
teach verifier to prevent pointer leaks.
Verifier will prevent
- any arithmetic on pointers
(except R10+Imm which is used to compute stack addresses)
- comparison of pointers
- p
On Mon, Oct 5, 2015 at 2:12 PM, Alexei Starovoitov wrote:
> On 10/5/15 2:00 PM, Kees Cook wrote:
>>
>> On Mon, Oct 5, 2015 at 1:48 PM, Alexei Starovoitov
>> wrote:
>>>
>>> >In order to let unprivileged users load and execute eBPF programs
>>> >teach verifier to prevent pointer leaks.
>>> >Verifier
On 10/5/15 2:16 PM, Andy Lutomirski wrote:
On Mon, Oct 5, 2015 at 2:12 PM, Alexei Starovoitov wrote:
On 10/5/15 2:00 PM, Kees Cook wrote:
On Mon, Oct 5, 2015 at 1:48 PM, Alexei Starovoitov
wrote:
In order to let unprivileged users load and execute eBPF programs
teach verifier to prevent po
On Mon, Oct 5, 2015 at 2:12 PM, Alexei Starovoitov wrote:
> On 10/5/15 2:00 PM, Kees Cook wrote:
>>
>> On Mon, Oct 5, 2015 at 1:48 PM, Alexei Starovoitov
>> wrote:
>>>
>>> >In order to let unprivileged users load and execute eBPF programs
>>> >teach verifier to prevent pointer leaks.
>>> >Verifier
On 10/5/15 2:00 PM, Kees Cook wrote:
On Mon, Oct 5, 2015 at 1:48 PM, Alexei Starovoitov wrote:
>In order to let unprivileged users load and execute eBPF programs
>teach verifier to prevent pointer leaks.
>Verifier will prevent
>- any arithmetic on pointers
> (except R10+Imm which is used to c
On Mon, Oct 5, 2015 at 1:48 PM, Alexei Starovoitov wrote:
> In order to let unprivileged users load and execute eBPF programs
> teach verifier to prevent pointer leaks.
> Verifier will prevent
> - any arithmetic on pointers
> (except R10+Imm which is used to compute stack addresses)
> - comparis
In order to let unprivileged users load and execute eBPF programs
teach verifier to prevent pointer leaks.
Verifier will prevent
- any arithmetic on pointers
(except R10+Imm which is used to compute stack addresses)
- comparison of pointers
- passing pointers to helper functions
- indirectly pass
28 matches
Mail list logo
