Re: [iovisor-dev] [PATCH v3 net-next 02/12] bpf/verifier: rework value tracking

Edward Cree wrote: > On 07/07/17 18:45, Nadav Amit wrote: >> For me changes such as: >> >>> if (dst_reg->min_value != BPF_REGISTER_MIN_RANGE) >>> - dst_reg->min_value -= min_val; >>> + dst_reg->min_value -= max_val; >> >> are purely

Re: [iovisor-dev] [PATCH v3 net-next 02/12] bpf/verifier: rework value tracking

Nadav Amit wrote: > Edward Cree wrote: > >> On 06/07/17 22:21, Nadav Amit wrote: >>> I find it a bit surprising that such huge changes that can affect security >>> and robustness are performed in one patch. >> In the first version of the series, this

Re: [iovisor-dev] [PATCH v3 net-next 02/12] bpf/verifier: rework value tracking

Edward Cree wrote: > On 06/07/17 22:21, Nadav Amit wrote: >> I find it a bit surprising that such huge changes that can affect security >> and robustness are performed in one patch. > In the first version of the series, this was two patches, with "feed >

Re: [iovisor-dev] [PATCH v3 net-next 02/12] bpf/verifier: rework value tracking

Edward Cree via iovisor-dev wrote: > Tracks value alignment by means of tracking known & unknown bits. > Tightens some min/max value checks and fixes a couple of bugs therein. > If pointer leaks are allowed, and adjust_ptr_min_max_vals returns -EACCES, > treat the

Re: [iovisor-dev] [PATCH v3 net-next 02/12] bpf/verifier: rework value tracking

Edward Cree via iovisor-dev wrote: > Tracks value alignment by means of tracking known & unknown bits. > Tightens some min/max value checks and fixes a couple of bugs therein. > If pointer leaks are allowed, and adjust_ptr_min_max_vals returns -EACCES, > treat the

Re: [iovisor-dev] LLVM backend handling of packed structures

Y Song <ys114...@gmail.com> wrote: > On Mon, Jul 3, 2017 at 8:23 PM, Nadav Amit via iovisor-dev > <iovisor-dev@lists.iovisor.org> wrote: >> I get a strange phenomenon with packed structs in which each byte is >> loaded in a different instruction. >> >

[iovisor-dev] LLVM backend handling of packed structures

I get a strange phenomenon with packed structs in which each byte is loaded in a different instruction. Consider for example xdp_prog1 for Linux samples. After building it, the disassembly starts with: xdp_prog1: 0: 61 12 04 00 00 00 00 00 r2 = *(u32 *)(r1 + 4) 1:

Re: [iovisor-dev] Wrong size-extension check in BPFDAGToDAGISel::SelectAddr

> > On Apr 13, 2017, at 3:39 PM, Alexei Starovoitov > wrote: > > On Thu, Apr 13, 2017 at 2:53 PM, Nadav Amit wrote: >> >> I sent a patch to https://reviews.llvm.org/D32055 . >> >> I do not know the LLVM test-suite, so please prepare a test

Re: [iovisor-dev] Wrong size-extension check in BPFDAGToDAGISel::SelectAddr

Thanks for your quick response. I don’t know how you got the trace from llvm trunk, but it seems the trunk is buggy as well. As you can see in the following line >r0 = *(u64 *)(r1 - 1879113726) This offset cannot fit within 16-bit. Check how this instruction is encoded and you will see it

[iovisor-dev] Wrong size-extension check in BPFDAGToDAGISel::SelectAddr

Using the LLVM backend of BPF, I sometimes get the wrong code to be generated. For example, for the following program: int bpf_prog1(void *ign) { volatile unsigned long t = 0x8983984739ull; return *(unsigned long *)((0x8fff0002ull) + t); } The generated code is 0: