Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1917039yba; Fri, 10 May 2019 03:19:34 -0700 (PDT) X-Google-Smtp-Source: APXvYqwMWH/YLLkSMmmS46uVk5S+EX5zgR1EsYO8axWsLTxXUwlgBZ+NOamjZ350otgW6mpVGTOr X-Received: by 2002:a62:4281:: with SMTP id h1mr12704995pfd.162.1557483574183; Fri, 10 May 2019 03:19:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557483574; cv=none; d=google.com; s=arc-20160816; b=TdERkb4eaew0W19qQRfgV1kFr2ul7QT4IPE+ZAtw/fu8vjJuVWDl3rVXR9sjniaEfb In2bkzzvOO4VRpQrI8HdJHykGYSy00UDmhWYUD5IdEbOtEoCfoPs6RChXwCDpg4XovHb kKtA+i3KqXEVs6K+VHGEK4HGD+FbUNsfwcj5O2aPnmgQTgVkOQ+pEZ+LMQYY1odPEU++ G5DKbM8Jr4KeV8nu4XuYSf01dwLpKXjCeOZwiepA15e7mlxpyh8XW8y2UTVbZMEjIUyB PTL62Cg6+wNLvuwzgtFBLx2wXEFi5JMLsgMNXtrGcygtWscXqAqZLjhTB2g/7P62skQL B5/w== 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:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=qz+stYvXt7DnxyGh7w2UEW303G1y2SoHoxPZJae/GgA=; b=GVFZZ3AN1XmQ0qchJ1vCUsSVpiR3iag7LIGP11sv6VUuB5cNZ1V92byrhhxD0gUrTE LKk1ZsOPNnU9e9xrwRVS8OW+05aQRC5jVI6713kpBZzdzRN/2WoIMXsmDUe/JBEc34bH ZCqIyT2lqSSrrB6Pn+uJfGA2QWKNwPO1gBs/D1mDz+nMPBDLeHtOMLtfan4zIJv8q4tK NOuveNlOlg3VcPeSDVbqyrayO41PIyOtEpDf7tiwKB204ZnH1nHLFubVlYoKTgViNCag x5ICnFJEA5z68HU7q9FH48sYL8RZOZWhJUyTBIbbUK2b/Tr4i9AWpnhKIho9iuWsBlkA 1+FA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kinvolk.io header.s=google header.b=jLHV+nOh; 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 134si6071471pga.492.2019.05.10.03.19.18; Fri, 10 May 2019 03:19:34 -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; dkim=pass header.i=@kinvolk.io header.s=google header.b=jLHV+nOh; 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 S1727708AbfEJKQl (ORCPT + 99 others); Fri, 10 May 2019 06:16:41 -0400 Received: from mail-lj1-f194.google.com ([209.85.208.194]:43330 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727468AbfEJKQj (ORCPT ); Fri, 10 May 2019 06:16:39 -0400 Received: by mail-lj1-f194.google.com with SMTP id z5so4595765lji.10 for ; Fri, 10 May 2019 03:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kinvolk.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=qz+stYvXt7DnxyGh7w2UEW303G1y2SoHoxPZJae/GgA=; b=jLHV+nOhTml6xqZeVSzwc8Wu8aDqJTmcu1Xv7gtwHbztumGmVTSlGpEcC1BS8n9Sv4 2H5IImNYZB0Fa1OcQIKTkaU6oyD100CqNorY1NofmoQOu41UADw2RdE4iB3RHoikSuLR OZTZ/eYaplomf/r5/xNQg4wR3U6oH//MXvNqk= 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:content-transfer-encoding; bh=qz+stYvXt7DnxyGh7w2UEW303G1y2SoHoxPZJae/GgA=; b=iR3UsEaG1kimNDn9RrWxnFsbyJxIzH1VSJKkezoMnSOhOH3DlQl1XHM6i1B5wxC+yB 3YdLKWYrfmDi5WMRP+TpEs8kkhDHHfWQO/Jxj/W9ZTV0tj+sSz6IKBtVYRTUoZuQIPc7 VRvDHDHrfvPNQEeWF2dxKjZKkWw7jpKmu3GEYT1KjSu3R5Msk6lXNwSNY5CQoPsORqgH dBJi/swbEOSqmjqfk/Kqa0JC8Y5fIVOKxZbWSHWy9lcVqh3zL0bSgeNfOrCSMj5iSCfy kAWzKg0kgz+dx9QO14p6EtEyCk1ihSj6I7PcxAdnuvYU66QtBCvwvLqRkbqaCKLuF7uD bgMg== X-Gm-Message-State: APjAAAVnSTmRJ9jKLgkFFYf1UkK+la0DpAMjq6Ji83hnbH9jg92ihNy8 9YngdbDaLDnPZEz6+vFvC7H/i+7jeLJGmit6adIr8w== X-Received: by 2002:a2e:74f:: with SMTP id i15mr5309596ljd.156.1557483397071; Fri, 10 May 2019 03:16:37 -0700 (PDT) MIME-Version: 1.0 References: <20190508160859.4380-1-krzesimir@kinvolk.io> <46056c60-f106-e539-b614-498cb1e9e3d0@iogearbox.net> In-Reply-To: <46056c60-f106-e539-b614-498cb1e9e3d0@iogearbox.net> From: Krzesimir Nowak Date: Fri, 10 May 2019 12:16:25 +0200 Message-ID: Subject: Re: [PATCH bpf v1] bpf: Fix undefined behavior in narrow load handling To: Daniel Borkmann Cc: bpf@vger.kernel.org, Alban Crequy , =?UTF-8?Q?Iago_L=C3=B3pez_Galeiras?= , Yonghong Song , Alexei Starovoitov , Martin KaFai Lau , Song Liu , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 9, 2019 at 11:30 PM Daniel Borkmann wrot= e: > > On 05/08/2019 06:08 PM, Krzesimir Nowak wrote: > > Commit 31fd85816dbe ("bpf: permits narrower load from bpf program > > context fields") made the verifier add AND instructions to clear the > > unwanted bits with a mask when doing a narrow load. The mask is > > computed with > > > > (1 << size * 8) - 1 > > > > where "size" is the size of the narrow load. When doing a 4 byte load > > of a an 8 byte field the verifier shifts the literal 1 by 32 places to > > the left. This results in an overflow of a signed integer, which is an > > undefined behavior. Typically the computed mask was zero, so the > > result of the narrow load ended up being zero too. > > > > Cast the literal to long long to avoid overflows. Note that narrow > > load of the 4 byte fields does not have the undefined behavior, > > because the load size can only be either 1 or 2 bytes, so shifting 1 > > by 8 or 16 places will not overflow it. And reading 4 bytes would not > > be a narrow load of a 4 bytes field. > > > > Reviewed-by: Alban Crequy > > Reviewed-by: Iago L=C3=B3pez Galeiras > > Fixes: 31fd85816dbe ("bpf: permits narrower load from bpf program conte= xt fields") > > Cc: Yonghong Song > > Signed-off-by: Krzesimir Nowak > > --- > > kernel/bpf/verifier.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > > index 09d5d972c9ff..950fac024fbb 100644 > > --- a/kernel/bpf/verifier.c > > +++ b/kernel/bpf/verifier.c > > @@ -7296,7 +7296,7 @@ static int convert_ctx_accesses(struct bpf_verifi= er_env *env) > > i= nsn->dst_reg, > > s= hift); > > insn_buf[cnt++] =3D BPF_ALU64_IMM(BPF_AND= , insn->dst_reg, > > - (1 << siz= e * 8) - 1); > > + (1ULL << = size * 8) - 1); > > } > > Makes sense, good catch & thanks for the fix! > > Could you also add a test case to test_verifier.c so we keep track of thi= s? > > Thanks, > Daniel Hi, A test for it is a bit tricky. I only found two 64bit fields that can be loaded narrowly - `sample_period` and `addr` in `struct bpf_perf_event_data`, so in theory I could have a test like follows: { "32bit loads of a 64bit field (both least and most significant words)", .insns =3D { BPF_LDX_MEM(BPF_W, BPF_REG_4, BPF_REG_1, offsetof(struct bpf_perf_event_data, addr)), BPF_LDX_MEM(BPF_W, BPF_REG_4, BPF_REG_1, offsetof(struct bpf_perf_event_data, addr) + 4), BPF_MOV64_IMM(BPF_REG_0, 0), BPF_EXIT_INSN(), }, .result =3D ACCEPT, .prog_type =3D BPF_PROG_TYPE_PERF_EVENT, }, The test like this would check that the program is not rejected, but it wasn't an issue. The test does not check if the verifier has transformed the narrow reads properly. Ideally the BPF program would do something like this: /* let's assume that low and high variables get their values from narrow lo= ad */ __u64 low =3D (__u32)perf_event->addr; __u64 high =3D (__u32)(perf_event->addr >> 32); __u64 addr =3D low | (high << 32); return addr !=3D perf_event->addr; But the test_verifier.c won't be able to run this, because BPF_PROG_TYPE_PERF_EVENT programs are not supported by the bpf_test_run_prog function. Any hints how to proceed here? Cheers, Krzesimir --=20 Kinvolk GmbH | Adalbertstr.6a, 10999 Berlin | tel: +491755589364 Gesch=C3=A4ftsf=C3=BChrer/Directors: Alban Crequy, Chris K=C3=BChl, Iago L= =C3=B3pez Galeiras Registergericht/Court of registration: Amtsgericht Charlottenburg Registernummer/Registration number: HRB 171414 B Ust-ID-Nummer/VAT ID number: DE302207000