* 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
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
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
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
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
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
* 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
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
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/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 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
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
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 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
* 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
* 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
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
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
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
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
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
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
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
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
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
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
-
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
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
28 matches
Mail list logo