Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753075AbaGBXEL (ORCPT ); Wed, 2 Jul 2014 19:04:11 -0400 Received: from mail-wg0-f47.google.com ([74.125.82.47]:36489 "EHLO mail-wg0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750946AbaGBXEI (ORCPT ); Wed, 2 Jul 2014 19:04:08 -0400 MIME-Version: 1.0 In-Reply-To: References: <1403913966-4927-1-git-send-email-ast@plumgrid.com> <1403913966-4927-9-git-send-email-ast@plumgrid.com> Date: Wed, 2 Jul 2014 16:04:05 -0700 Message-ID: Subject: Re: [PATCH RFC net-next 08/14] bpf: add eBPF verifier From: Alexei Starovoitov To: Chema Gonzalez Cc: "David S. Miller" , Ingo Molnar , Linus Torvalds , Steven Rostedt , Daniel Borkmann , Eric Dumazet , Peter Zijlstra , Arnaldo Carvalho de Melo , Jiri Olsa , Thomas Gleixner , "H. Peter Anvin" , Andrew Morton , Kees Cook , Linux API , Network Development , LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 2, 2014 at 3:22 PM, Chema Gonzalez wrote: >> + * - unreachable insns exist (shouldn't be a forest. program = one function) > This seems to me an unnecessary style restriction on user code. unreachable instructions to me is a ticking time bomb of potential exploits. Definitely should be rejected. >> +#define _(OP) ({ int ret = OP; if (ret < 0) return ret; }) > +1 to removing the _ macro. If you want to avoid the 3 lines (is there > anything in the style guide against "if ((err=OP) < 0) ..." ?), at assignment and function call inside 'if' ? I don't like such style. > least use some meaningful macro name (DO_AND_CHECK, or something like > that). Try replacing _ with any other name and see how bad it will look. I tried with MACRO_NAME and with 'if (err) goto' and with 'if (err) return', before I converged on _ macro. I think it's a hidden gem of this patch. > Can you please add: > > + } else if (class == BPF_LD) { > + if (BPF_MODE(insn->code) == BPF_ABS) { > + pr_cont("(%02x) r0 = *(%s *)skb[%d]\n", > + insn->code, > + bpf_ldst_string[BPF_SIZE(insn->code) >> 3], > + insn->imm); > + } else if (BPF_MODE(insn->code) == BPF_IND) { > + pr_cont("(%02x) r0 = *(%s *)skb[r%d + %d]\n", > + insn->code, > + bpf_ldst_string[BPF_SIZE(insn->code) >> 3], > + insn->src_reg, insn->imm); > + } else { > + pr_cont("BUG_ld_%02x\n", insn->code); > + return; > + } > > Note that I'm hardcoding r0 (instead of using %d for insn->dst_reg) > because that's how ebpf writes the instructions. ohh yes. it's a copy paste error, since it was in a different file before. Will definitely add. Thanks! >> +static void init_reg_state(struct reg_state *regs) >> +{ >> + struct reg_state *reg; >> + int i; >> + >> + for (i = 0; i < MAX_BPF_REG; i++) { >> + regs[i].ptr = INVALID_PTR; >> + regs[i].read_ok = false; >> + regs[i].imm = 0xbadbad; >> + } >> + reg = regs + BPF_REG_FP; > Any reason you switching from the array syntax to the pointer one? I > find "reg = regs[BPF_REG_FP];" more readable (and the one you chose in > the loop). in this function no particular reason. It felt a bit less verbose, but I can make the change. >> + reg = regs + BPF_REG_1; /* 1st arg to a function */ >> + reg->ptr = PTR_TO_CTX; > Wait, doesn't this depend on doing "BPF_MOV64_REG(BPF_REG_CTX, > BPF_REG_ARG1)" (the bpf-to-ebpf prologue), which is only enforced on > filters converted from bpf? In fact, shouldn't this set > regs[BPF_REG_CTX] instead of regs[BPF_REG_1] ? nope. it's REG_1. as you said r6=r1 is only emitted by converted classic filters. Verifier will see this 'r6=r1' assignment and will copy the r1 type into r6. Thank you for review! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/