Received: by 10.223.164.221 with SMTP id h29csp2709550wrb; Thu, 2 Nov 2017 16:13:20 -0700 (PDT) X-Google-Smtp-Source: ABhQp+RcXXuQkNbckchPlR34cCLQn632pUIFqJnYacUYZXWPCKZg48KyWYWN0QWQGxCGRjsTMQjA X-Received: by 10.159.252.200 with SMTP id o8mr4849158pls.80.1509664400568; Thu, 02 Nov 2017 16:13:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1509664400; cv=none; d=google.com; s=arc-20160816; b=NH4mR+cI519R1zR7NJ0EjqnPRqGuk5CKBu3nRsEnBT7+yI4PcUVaFs/9pmVshPpqow HML98PyaM5ZGhPW27yizpMrh5nGh6ClwCVWK3boxxBQFfpOrxWr47c3mT3KQ1UqYTPHs rvj3OHtpsJwtllzF9fbKa11CtlHneyoPGjickymL04HXzvKqBl3jEnsSBhikQO2dFKar 9tSZkx8iRG9zUs6xPq7m/4rL2VLlyTixit/3ZU3rloeSYP4BjO6orru+ziSKiAMHquPZ jfnKPS6DG2tKsBk8D89yFK8XFYrLWZR5lXhjAa7Umu3l+CiFy4gIXApxww+dOA8ZgsOd cgLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :references:subject:cc:to:mime-version:user-agent:from:date :message-id:arc-authentication-results; bh=RjFeMS+/VxYrWTumBu7IR0e3/ChK8/o/QrQjGYbyctg=; b=hHWYqQhTFM9jJ+i7ATux3bu3GhX/H+BemHeykqcf8UJ3HuvtzigOqen749iqljTf5s nxPhpWyGmkDfJ3n0ARlHRK+q3ad4gXnFYMOUhhBCfWAGSqWN5zp2/sfuzFtCtEBU+Sub 5gLk3hzJm/UoxXc8IOcLLtANkRSkGbc3tlp/jCKNMRhdldKUpozxfjSwVvKr2vfz5xLd dnpzkOnfyMvOn+dfzpMWui8YCEfTEAShYZJaNr1g/CULt7DT/uhI1s3eusejUfsRsGJ+ KE4JkB46TtRCKbbmljenC83wpO7tYy75cmBFtIcYWdsdbuCl7lYBLIEorkeNr/q/og58 8X8A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h132si4933084pfe.87.2017.11.02.16.13.07; Thu, 02 Nov 2017 16:13:20 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964931AbdKBXMY (ORCPT + 98 others); Thu, 2 Nov 2017 19:12:24 -0400 Received: from www62.your-server.de ([213.133.104.62]:44106 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964895AbdKBXMW (ORCPT ); Thu, 2 Nov 2017 19:12:22 -0400 Received: from [194.230.159.142] (helo=localhost.localdomain) by www62.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.85_2) (envelope-from ) id 1eAOej-0004lR-Oe; Fri, 03 Nov 2017 00:12:13 +0100 Message-ID: <59FBA64D.1050400@iogearbox.net> Date: Fri, 03 Nov 2017 00:12:13 +0100 From: Daniel Borkmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Josef Bacik , rostedt@goodmis.org, mingo@redhat.com, davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, ast@kernel.org, kernel-team@fb.com CC: Josef Bacik Subject: Re: [PATCH 1/2] bpf: add a bpf_override_function helper References: <1509633431-2184-1-git-send-email-josef@toxicpanda.com> <1509633431-2184-2-git-send-email-josef@toxicpanda.com> In-Reply-To: <1509633431-2184-2-git-send-email-josef@toxicpanda.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.99.2/24010/Thu Nov 2 13:07:00 2017) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Josef, one more issue I just noticed, see comment below: On 11/02/2017 03:37 PM, Josef Bacik wrote: [...] > diff --git a/include/linux/filter.h b/include/linux/filter.h > index cdd78a7beaae..dfa44fd74bae 100644 > --- a/include/linux/filter.h > +++ b/include/linux/filter.h > @@ -458,7 +458,8 @@ struct bpf_prog { > locked:1, /* Program image locked? */ > gpl_compatible:1, /* Is filter GPL compatible? */ > cb_access:1, /* Is control block accessed? */ > - dst_needed:1; /* Do we need dst entry? */ > + dst_needed:1, /* Do we need dst entry? */ > + kprobe_override:1; /* Do we override a kprobe? */ > kmemcheck_bitfield_end(meta); > enum bpf_prog_type type; /* Type of BPF program */ > u32 len; /* Number of filter blocks */ [...] > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > index d906775e12c1..f8f7927a9152 100644 > --- a/kernel/bpf/verifier.c > +++ b/kernel/bpf/verifier.c > @@ -4189,6 +4189,8 @@ static int fixup_bpf_calls(struct bpf_verifier_env *env) > prog->dst_needed = 1; > if (insn->imm == BPF_FUNC_get_prandom_u32) > bpf_user_rnd_init_once(); > + if (insn->imm == BPF_FUNC_override_return) > + prog->kprobe_override = 1; > if (insn->imm == BPF_FUNC_tail_call) { > /* If we tail call into other programs, we > * cannot make any assumptions since they can > diff --git a/kernel/events/core.c b/kernel/events/core.c > index 9660ee65fbef..0d7fce52391d 100644 > --- a/kernel/events/core.c > +++ b/kernel/events/core.c > @@ -8169,6 +8169,13 @@ static int perf_event_set_bpf_prog(struct perf_event *event, u32 prog_fd) > return -EINVAL; > } > > + /* Kprobe override only works for kprobes, not uprobes. */ > + if (prog->kprobe_override && > + !(event->tp_event->flags & TRACE_EVENT_FL_KPROBE)) { > + bpf_prog_put(prog); > + return -EINVAL; > + } Can we somehow avoid the prog->kprobe_override flag here completely and also same in the perf_event_attach_bpf_prog() handler? Reason is that it's not reliable for bailing out this way: Think of the main program you're attaching doesn't use bpf_override_return() helper, but it tail-calls into other BPF progs that make use of it instead. So above check would be useless and will fail and we continue to attach the prog for probes where it's not intended to be used. We've had similar issues in the past e.g. c2002f983767 ("bpf: fix checking xdp_adjust_head on tail calls") is just one of those. Thus, can we avoid the flag altogether and handle such error case differently? > if (is_tracepoint || is_syscall_tp) { > int off = trace_event_get_offsets(event->tp_event); Thanks, Daniel From 1582965462915356698@xxx Thu Nov 02 14:38:25 +0000 2017 X-GM-THRID: 1582965462915356698 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread