Re: Alignment in BPF verifier

2017-05-25 Thread David Miller
From: Daniel Borkmann Date: Tue, 23 May 2017 23:27:20 +0200 > On 05/23/2017 09:45 PM, Alexei Starovoitov wrote: >> On 5/23/17 7:41 AM, Edward Cree wrote: >>> Hmm, that means that we can't do arithmetic on a >>> PTR_TO_MAP_VALUE_OR_NULL, we have to convert it to a

Re: Alignment in BPF verifier

2017-05-24 Thread Alexei Starovoitov
On 5/24/17 6:46 AM, Edward Cree wrote: On 23/05/17 22:27, Daniel Borkmann wrote: On 05/23/2017 09:45 PM, Alexei Starovoitov wrote: On 5/23/17 7:41 AM, Edward Cree wrote: Hmm, that means that we can't do arithmetic on a PTR_TO_MAP_VALUE_OR_NULL, we have to convert it to a PTR_TO_MAP_VALUE

Re: Alignment in BPF verifier

2017-05-24 Thread Edward Cree
On 23/05/17 22:27, Daniel Borkmann wrote: > On 05/23/2017 09:45 PM, Alexei Starovoitov wrote: >> On 5/23/17 7:41 AM, Edward Cree wrote: >>> Hmm, that means that we can't do arithmetic on a >>> PTR_TO_MAP_VALUE_OR_NULL, we have to convert it to a PTR_TO_MAP_VALUE >>> first by NULL-checking it.

Re: Alignment in BPF verifier

2017-05-23 Thread Alexei Starovoitov
On 5/23/17 10:43 AM, Edward Cree wrote: Another issue: it looks like the min/max_value handling for subtraction is bogus. In adjust_reg_min_max_vals() we have if (dst_reg->min_value != BPF_REGISTER_MIN_RANGE) dst_reg->min_value -= min_val; if (dst_reg->max_value !=

Re: Alignment in BPF verifier

2017-05-23 Thread Daniel Borkmann
On 05/23/2017 09:45 PM, Alexei Starovoitov wrote: On 5/23/17 7:41 AM, Edward Cree wrote: I'm still plugging away at this... it's going to be quite a big patch and rewrite a lot of stuff (and I'm not sure I'll be able to break it into smaller bisectable patches). And of course I have more

Re: Alignment in BPF verifier

2017-05-23 Thread Alexei Starovoitov
On 5/23/17 7:41 AM, Edward Cree wrote: I'm still plugging away at this... it's going to be quite a big patch and rewrite a lot of stuff (and I'm not sure I'll be able to break it into smaller bisectable patches). And of course I have more questions. In check_packet_ptr_add(), we forbid

Re: Alignment in BPF verifier

2017-05-23 Thread Edward Cree
Another issue: it looks like the min/max_value handling for subtraction is bogus. In adjust_reg_min_max_vals() we have if (dst_reg->min_value != BPF_REGISTER_MIN_RANGE) dst_reg->min_value -= min_val; if (dst_reg->max_value != BPF_REGISTER_MAX_RANGE) dst_reg->max_value -=

Re: Alignment in BPF verifier

2017-05-23 Thread Edward Cree
I'm still plugging away at this... it's going to be quite a big patch and rewrite a lot of stuff (and I'm not sure I'll be able to break it into smaller bisectable patches). And of course I have more questions. In check_packet_ptr_add(), we forbid adding a negative constant to a packet ptr.

Re: Alignment in BPF verifier

2017-05-19 Thread Daniel Borkmann
On 05/19/2017 10:39 PM, David Miller wrote: From: Edward Cree Date: Fri, 19 May 2017 21:00:13 +0100 Well, I've managed to get somewhat confused by reg->id. In particular, I'm unsure which bpf_reg_types can have an id, and what exactly it means. There seems to be some

Re: Alignment in BPF verifier

2017-05-19 Thread David Miller
From: Edward Cree Date: Fri, 19 May 2017 21:00:13 +0100 > Here's what I'm thinking of doing: > struct bpf_reg_state { > enum bpf_reg_type type; > union { > /* valid when type == PTR_TO_PACKET */ > u16 range; > > /* valid when type ==

Re: Alignment in BPF verifier

2017-05-19 Thread David Miller
From: Edward Cree Date: Fri, 19 May 2017 21:00:13 +0100 > Well, I've managed to get somewhat confused by reg->id. > In particular, I'm unsure which bpf_reg_types can have an id, and what > exactly it means. There seems to be some code that checks around map value >