From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0A4C5C43381 for ; Fri, 1 Mar 2019 14:10:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CC71520848 for ; Fri, 1 Mar 2019 14:10:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=cloudflare.com header.i=@cloudflare.com header.b="s2OUMJcY" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728357AbfCAOKp (ORCPT ); Fri, 1 Mar 2019 09:10:45 -0500 Received: from mail-qt1-f195.google.com ([209.85.160.195]:39249 "EHLO mail-qt1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726195AbfCAOKp (ORCPT ); Fri, 1 Mar 2019 09:10:45 -0500 Received: by mail-qt1-f195.google.com with SMTP id o6so27826705qtk.6 for ; Fri, 01 Mar 2019 06:10:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CK+15u+KZQxGdFQWMWwvo51W8J4wZoddrEkF+faOz8I=; b=s2OUMJcYPyMb8F8CW8ompCtXmlOJ5ih+zKWV6Ao2X66dcHLP9EG9xxOtfPyLSSZNhX Qm3iqOTiu2IC2Xq1l/wXdyA9379UQqLCxSsdLJ1kpYff2FvQpLXVGGfrnlFHplTvPkDt OPGfzsbfk/eZUQ/Lma/dHkFBhG02Ftt20cksE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CK+15u+KZQxGdFQWMWwvo51W8J4wZoddrEkF+faOz8I=; b=FG0YcN3Z08yt8izKerLx7o8WoDsXQsKh06PlFvNo/qlALR86IUOG24296+vC99e7V/ GzXIlZAz4b8SswdtX2ulxQXb+DJ2Ho7JRoKa4I3FDNEZqvhYVCUQB3Ny8YMq7EF5BsIe jtRBxI51m0SVGOKek4scOLYc9DK5RAFH2DWItmnnetqiqZT8CI71ahuexm5/QAz7I2aG s2UMojJtdEHHCkx+uFbNTo2vDlpo1vJztP98ztJ9OijN71vwBI1PUEkJeZqOP2ryQ4JN 9/4b8xDKs+y6AJLk3NEJ26CCzWgNaUFnPpHzvXT5xGFgnwQMlQbIwOEH+Tjjlz42ifXn mc2g== X-Gm-Message-State: APjAAAXxbpCN5a3Xe6x5PEy4xXc2ocHhgOnewMO+IfknQyjZGjm2ugtF 0PjH5KFOg74QEt35mBllY6zGnF6bmlTR0nytzT0BSg== X-Google-Smtp-Source: APXvYqw5lHusvt/xQWdfGuhbcJ1a+OZXLP/4Y2u8Y2aanvUGvuTOeoL/eu9JcFj10PFFasnwYfnKhtvOZc1aNPxGquI= X-Received: by 2002:ac8:3802:: with SMTP id q2mr3946214qtb.325.1551449443854; Fri, 01 Mar 2019 06:10:43 -0800 (PST) MIME-Version: 1.0 References: <20190301113901.29448-1-afabre@cloudflare.com> In-Reply-To: From: Marek Majkowski Date: Fri, 1 Mar 2019 15:10:32 +0100 Message-ID: Subject: Re: SOCKET_FILTER regression - eBPF can't subtract when attached from unprivileged user To: Daniel Borkmann Cc: Arthur Fabre , ast@kernel.org, netdev@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Great, appreciated. One more thing (since upgrading kernels takes time) do you think I can amend eBPF on my side to avoid triggering this? Naive stuff like this doesn't work sadly: uint64_t delta = b + ~a + 1; I tried couple more variants with uint32_t types, but to no avail. Ideas? Marek On Fri, Mar 1, 2019 at 3:04 PM Daniel Borkmann wrote: > > On 03/01/2019 12:39 PM, Arthur Fabre wrote: > > I can reproduce this on 4.19.0-3-amd64 both with, and without the JIT enabled. > > > > Dumping the "root" and "non-root" programs with bpftool, > > the subtraction instructions differ: > > > > "non-root": > > 0: (85) call bpf_ktime_get_ns#74944 > > 1: (bf) r7 = r0 > > 2: (85) call bpf_ktime_get_ns#74944 > > 3: (bf) r6 = r0 > > 4: (bf) r8 = r6 > > 5: (b4) w11 = -1 > > 6: (1f) r11 -= r8 > > 7: (4f) r11 |= r8 > > 8: (87) r11 = -r11 > > 9: (c7) r11 s>>= 63 > > 10: (5f) r8 &= r11 > > > > "root": > > 0: (85) call bpf_ktime_get_ns#74944 > > 1: (bf) r7 = r0 > > 2: (85) call bpf_ktime_get_ns#74944 > > 3: (bf) r6 = r0 > > 4: (bf) r8 = r6 > > > > The remainder of the instructions are for writing the results in the map, > > and the instructions are identical. > > > > I believe the extra instructions come from "fixup_bpf_calls" in the verifier: > > > > if (isneg) > > *patch++ = BPF_ALU64_IMM(BPF_MUL, off_reg, -1); > > *patch++ = BPF_MOV32_IMM(BPF_REG_AX, aux->alu_limit - 1); > > *patch++ = BPF_ALU64_REG(BPF_SUB, BPF_REG_AX, off_reg); > > *patch++ = BPF_ALU64_REG(BPF_OR, BPF_REG_AX, off_reg); > > *patch++ = BPF_ALU64_IMM(BPF_NEG, BPF_REG_AX, 0); > > *patch++ = BPF_ALU64_IMM(BPF_ARSH, BPF_REG_AX, 63); > > if (issrc) { > > *patch++ = BPF_ALU64_REG(BPF_AND, BPF_REG_AX, > > off_reg); > > insn->src_reg = BPF_REG_AX; > > } else { > > *patch++ = BPF_ALU64_REG(BPF_AND, off_reg, > > BPF_REG_AX); > > } > > > > This was introduced by "bpf: prevent out of bounds speculation on pointer arithmetic" > > (https://patchwork.ozlabs.org/patch/1039606/). > > I don't yet understand what's going on. > > Ok, sigh, fix is this, sorry about the braino: > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > index cdd2cb01f789..5b3cd384df1d 100644 > --- a/kernel/bpf/verifier.c > +++ b/kernel/bpf/verifier.c > @@ -7629,7 +7629,8 @@ static int fixup_bpf_calls(struct bpf_verifier_env *env) > u32 off_reg; > > aux = &env->insn_aux_data[i + delta]; > - if (!aux->alu_state) > + if (!aux->alu_state || > + aux->alu_state == BPF_ALU_NON_POINTER) > continue; > > isneg = aux->alu_state & BPF_ALU_NEG_VALUE; > > And this also makes the test work again: > > foo@test:/root/d0bb75a8c62cc35bec2b342054084aab-7cc37a3a93c8b4028e977f3131feaf7f8705e6a7$ ./ebpf-bug > 0 -> 0 0x0000000000000000 > 1 -> 54645145816 0x0000000cb91ac0d8 > 2 -> 54645145860 0x0000000cb91ac104 > 3 -> 44 0x000000000000002c > foo@test:/root/d0bb75a8c62cc35bec2b342054084aab-7cc37a3a93c8b4028e977f3131feaf7f8705e6a7$ exit > root@test:~/d0bb75a8c62cc35bec2b342054084aab-7cc37a3a93c8b4028e977f3131feaf7f8705e6a7# ./ebpf-bug > 0 -> 0 0x0000000000000000 > 1 -> 57984017624 0x0000000d801de4d8 > 2 -> 57984017673 0x0000000d801de509 > 3 -> 49 0x0000000000000031 > > I'll cook it as proper patch in a bit along with a test case. > > Thanks for reporting! > Daniel