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=-6.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_PASS 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 CCC5CC43381 for ; Fri, 1 Mar 2019 01:06:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 91F1620863 for ; Fri, 1 Mar 2019 01:06:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=cloudflare.com header.i=@cloudflare.com header.b="TIXvVhj8" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733046AbfCABGz (ORCPT ); Thu, 28 Feb 2019 20:06:55 -0500 Received: from mail-qt1-f180.google.com ([209.85.160.180]:39812 "EHLO mail-qt1-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728005AbfCABGz (ORCPT ); Thu, 28 Feb 2019 20:06:55 -0500 Received: by mail-qt1-f180.google.com with SMTP id o6so25930326qtk.6 for ; Thu, 28 Feb 2019 17:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=NEgXjfFLDvnRiqbDL1waj9KSw0MgcqwXzRUUbvITpnE=; b=TIXvVhj8PbEe1w+H5wGplLcOftLomYVdDV1D/erHooYi3JMgvL9gcZ+bRnZ6UeVdXK cIDfGWjA2LQqbYlp2SkSWBE1yhzT+XVS1HkLnn0X3BNB9Qrut5F/CxMFnBvETCJRl7On FZuGfRQZ+EIdNBy/ai9Y4FxcX5j6viNU9IqEo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NEgXjfFLDvnRiqbDL1waj9KSw0MgcqwXzRUUbvITpnE=; b=q/9TMgaBnMEQtWh2NhaQ9spCvOKGkpKLJg4QOat+b6j6OJZZHNPvdJmBW1AYhJQpwv Un834Xv/+gnGACrdinaQWbX72UeWH0mGjdo0Ro589ijgndkjuB73mr37a6BmmMGRYuD5 A8X3fBImFPQblNctMmrSCD4ON8iG6EVqFN55g/JyYnWb4CHVdGDN1Sh0bEsI+A6XL9ja 6J79YiHZfv8k4TcBvEZ+4/jNStiiPO5xJpsFprwin4+nrn1fR8Qrp54jX+cNPfDLs+iX cUn6nhNlIVj3xtCFJv2fYTfAL0LkiOtTk+xOG3C6jXczwdrIFYf6RjCwFlM5B1bQYLQC DveQ== X-Gm-Message-State: APjAAAVFAbptwKiR0rnRNwfCjqFblxTm19i8K0XrVoS8KntPKuNcBAlf T46KTNEJ46FlXjTcifQG2MlSDI1V2dC5Hj87DLbdgw== X-Google-Smtp-Source: APXvYqx/6uH7x5UCjDv3k3+CLdyfAmtI7jEpMt4tZ48Av7gwTNHsOMPZaSdh+mWjRPuVfeuwohL9WLu/tsYpeHFbjl0= X-Received: by 2002:ac8:3802:: with SMTP id q2mr1805459qtb.325.1551402413754; Thu, 28 Feb 2019 17:06:53 -0800 (PST) MIME-Version: 1.0 From: Marek Majkowski Date: Fri, 1 Mar 2019 02:06:42 +0100 Message-ID: Subject: SOCKET_FILTER regression - eBPF can't subtract when attached from unprivileged user To: ast@kernel.org, Daniel Borkmann , 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 Howdy, After some dramatic debugging, I think I managed to isolate a problem that looks like a funny eBPF runtime regression. It seems to be introduced somewhere after 4.14. The eBPF in question is running on network sockets with SO_ATTACH_BPF. The BPF_PROG_TYPE_SOCKET_FILTER code: uint64_t a = bpf_ktime_get_ns(); uint64_t b = bpf_ktime_get_ns(); uint64_t delta = b - a; if ((int64_t)delta > 0) { Depending on a context, the "delta" variable is set to a wrong value. The compiled bytecode seems fine: Disassembly of section socket1: bpf_prog1: ; { 0: 85 00 00 00 05 00 00 00 call 5 ; uint64_t a = bpf_ktime_get_ns(); 1: bf 07 00 00 00 00 00 00 r7 = r0 ; uint64_t b = bpf_ktime_get_ns(); 2: 85 00 00 00 05 00 00 00 call 5 3: bf 06 00 00 00 00 00 00 r6 = r0 ; uint64_t delta = b - a; 4: bf 68 00 00 00 00 00 00 r8 = r6 5: 1f 78 00 00 00 00 00 00 r8 -= r7 ; if ((int64_t)delta > 0) { 6: b7 01 00 00 01 00 00 00 r1 = 1 7: 6d 81 0a 00 00 00 00 00 if r1 s> r8 goto +10 XXX The code runs fine from root. From unprivileged user though, the value of "delta" is a wrapped negative. Both "a" and "b" are fine in both root and non-root cases. Technically bpf_ktime_get_ns() can go backwards, but this isn't the case here. It does seem like the problem is with the behaiviour of ... the subtraction operation when running from SO_ATTACH_BPF executed by non-root? Code: https://gist.github.com/majek/d0bb75a8c62cc35bec2b342054084aab git clone https://gist.github.com/majek/d0bb75a8c62cc35bec2b342054084aab cd d0bb75a8c62cc35bec2b342054084aab make Then: $ sudo ./ebpf-bug 0 -> 0 0x0000000000000000 1 -> 12585651690481 0x00000b72534c5bf1 2 -> 12585651690697 0x00000b72534c5cc9 3 -> 216 0x00000000000000d8 $ ./ebpf-bug 0 -> 1 0x0000000000000001 1 -> 12581437028489 0x00000b715815b889 2 -> 12581437028689 0x00000b715815b951 3 -> 18446731492272523127 0xfffff48ea7ea4777 "1" shows "a" "2" shows "b" "3" shows "detla" As you see "delta" is off the scale for unprivileged user run. I don't see any reason why root vs non-root should make any difference for this code. For completeness, this was tested with jit disabled: $ cat /proc/version Linux version 5.0.0-rc6+ (marek@mrbreeze) (gcc version 7.3.0) $ sudo sysctl -a|grep -i jit net.core.bpf_jit_enable = 0 net.core.bpf_jit_harden = 0 The same test on 4.14 seems fine: $ cat /proc/version Linux version 4.14.83-cloudflare-2018.11.4 (gcc version 8.2.0 (GCC)) $ sudo ./ebpf-bug 0 -> 0 0x0000000000000000 1 -> 7435203111991321 0x001a6a472052b819 2 -> 7435203111991429 0x001a6a472052b885 3 -> 108 0x000000000000006c $ ./ebpf-bug 0 -> 0 0x0000000000000000 1 -> 7435205114618775 0x001a6a4797b06397 2 -> 7435205114618883 0x001a6a4797b06403 3 -> 108 0x000000000000006c Cheers, Marek