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=-3.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_PASS,USER_AGENT_GIT 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 63695C43381 for ; Fri, 1 Mar 2019 11:39:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2501620851 for ; Fri, 1 Mar 2019 11:39:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=cloudflare.com header.i=@cloudflare.com header.b="n4XAw5Tn" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733102AbfCALjF (ORCPT ); Fri, 1 Mar 2019 06:39:05 -0500 Received: from mail-wr1-f44.google.com ([209.85.221.44]:40221 "EHLO mail-wr1-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727492AbfCALjE (ORCPT ); Fri, 1 Mar 2019 06:39:04 -0500 Received: by mail-wr1-f44.google.com with SMTP id q1so25534785wrp.7 for ; Fri, 01 Mar 2019 03:39:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=3hyL6U44HLFUdgSvpsXILb9rSBckNCjDr8PLFsdLHK0=; b=n4XAw5Tn5Kx8gSjiTTybc56eDsOOmrWN5ucvNUAuggl2okc3MpMAMG167SXEmsjBnu X5BPZWZRcsGhZ0rE4c3dYTEQSzGg2lqg0sTMgknlnLJ4nEMQPqAAnOruNE+OJy5wTJ9Q FYzxJ3L9wZhP0sFwAztlS9HfeFNJt9o9BmJtc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=3hyL6U44HLFUdgSvpsXILb9rSBckNCjDr8PLFsdLHK0=; b=DIwRUWXmQmKMd1qtotT2yfRnSUJnj2lYyOlfLKbGR0QO3jvEFftHx0xjfsHlIXEOp7 1rgxpZjqgTf9D+z5hTgHXSbxH/1qkBAs6c1y+dQPHo0j1GRNFjc19jkFvx7g1co0sYJK Hd78SOazpdN3mHc1bl75A3gCLjfdXjuusrpZQvOFYI6IGL6SrFJKSYYJS9l/k9SSyilc BZl9ttT6Z0jlX42cVn2siiiU1G/pOR57GTGb6wC4ZFHdsHB0C1U8LCYlgRUxI0vs3YTC i9J94h8Ge5rawJil1upU357AUg7xmS3FfS1yk1+VjuqvL18URBtXF98fWuOvzEIEjUx5 q5QQ== X-Gm-Message-State: APjAAAUVpkAOscx+d1G4JjohV6RqYykMgTKthOqwKCLW9ro9LzZzFZwD 1xtA+PHY1bqoaTUv/ODH/d9QJg== X-Google-Smtp-Source: APXvYqyk8dKu9emEG11E9mVS0P788xko9N17XU/TteGpvcgya0slYWu9zZCE189HaDOEnbBDBFY+Qw== X-Received: by 2002:a5d:53cf:: with SMTP id a15mr3083232wrw.163.1551440342890; Fri, 01 Mar 2019 03:39:02 -0800 (PST) Received: from localhost.localdomain ([217.138.62.245]) by smtp.gmail.com with ESMTPSA id p1sm20651080wrx.50.2019.03.01.03.39.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Mar 2019 03:39:02 -0800 (PST) From: Arthur Fabre To: marek@cloudflare.com Cc: ast@kernel.org, daniel@iogearbox.net, netdev@vger.kernel.org, afabre@cloudflare.com Subject: RE: SOCKET_FILTER regression - eBPF can't subtract when attached from unprivileged user Date: Fri, 1 Mar 2019 11:39:01 +0000 Message-Id: <20190301113901.29448-1-afabre@cloudflare.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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. Cheers, Arthur