On 8/21/17 2:00 PM, Daniel Borkmann wrote:
On 08/21/2017 10:44 PM, Edward Cree wrote:
On 21/08/17 21:27, Daniel Borkmann wrote:
On 08/21/2017 08:36 PM, Edward Cree wrote:
On 19/08/17 00:37, Alexei Starovoitov wrote:
[...]
I'm tempted to just rip out env->varlen_map_value_access and always
ch
On 8/21/17 1:24 PM, Edward Cree wrote:
On 18/08/17 15:16, Edward Cree wrote:
On 18/08/17 04:21, Alexei Starovoitov wrote:
It seems you're trying to sort-of do per-fake-basic block liveness
analysis, but our state_list_marks are not correct if we go with
canonical basic block definition, since w
On 08/21/2017 10:44 PM, Edward Cree wrote:
On 21/08/17 21:27, Daniel Borkmann wrote:
On 08/21/2017 08:36 PM, Edward Cree wrote:
On 19/08/17 00:37, Alexei Starovoitov wrote:
[...]
I'm tempted to just rip out env->varlen_map_value_access and always check
the whole thing, because honestly I d
On 21/08/17 21:27, Daniel Borkmann wrote:
> On 08/21/2017 08:36 PM, Edward Cree wrote:
>> On 19/08/17 00:37, Alexei Starovoitov wrote:
> [...]
>> I'm tempted to just rip out env->varlen_map_value_access and always check
>> the whole thing, because honestly I don't know what it was meant to do
>>
On 08/21/2017 08:36 PM, Edward Cree wrote:
On 19/08/17 00:37, Alexei Starovoitov wrote:
[...]
I'm tempted to just rip out env->varlen_map_value_access and always check
the whole thing, because honestly I don't know what it was meant to do
originally or how it can ever do any useful pruning.
On 18/08/17 15:16, Edward Cree wrote:
> On 18/08/17 04:21, Alexei Starovoitov wrote:
>> It seems you're trying to sort-of do per-fake-basic block liveness
>> analysis, but our state_list_marks are not correct if we go with
>> canonical basic block definition, since we mark the jump insn and
>> not
On 19/08/17 00:37, Alexei Starovoitov wrote:
> that '14: safe' above is not correct.
>
> Disabling liveness as:
> @@ -3282,7 +3288,7 @@ static bool regsafe(struct bpf_reg_state *rold,
> struct bpf_reg_state *rcur,
> bool varlen_map_access, struct idpair *idma
On 8/18/17 7:16 AM, Edward Cree wrote:
On 18/08/17 04:21, Alexei Starovoitov wrote:
On 8/15/17 12:34 PM, Edward Cree wrote:
State of a register doesn't matter if it wasn't read in reaching an exit;
a write screens off all reads downstream of it from all explored_states
upstream of it.
This al
On 18/08/17 04:21, Alexei Starovoitov wrote:
> On 8/15/17 12:34 PM, Edward Cree wrote:
>> State of a register doesn't matter if it wasn't read in reaching an exit;
>> a write screens off all reads downstream of it from all explored_states
>> upstream of it.
>> This allows us to prune many more br
On 8/15/17 12:34 PM, Edward Cree wrote:
State of a register doesn't matter if it wasn't read in reaching an exit;
a write screens off all reads downstream of it from all explored_states
upstream of it.
This allows us to prune many more branches; here are some processed insn
counts for some Cil
From: Daniel Borkmann
Date: Wed, 16 Aug 2017 00:12:58 +0200
> On 08/15/2017 09:34 PM, Edward Cree wrote:
>> State of a register doesn't matter if it wasn't read in reaching an
>> exit;
>> a write screens off all reads downstream of it from all
>> explored_states
>> upstream of it.
>> This a
On 08/15/2017 09:34 PM, Edward Cree wrote:
State of a register doesn't matter if it wasn't read in reaching an exit;
a write screens off all reads downstream of it from all explored_states
upstream of it.
This allows us to prune many more branches; here are some processed insn
counts for so
State of a register doesn't matter if it wasn't read in reaching an exit;
a write screens off all reads downstream of it from all explored_states
upstream of it.
This allows us to prune many more branches; here are some processed insn
counts for some Cilium programs:
Program bef
13 matches
Mail list logo
