Received: by 10.192.165.148 with SMTP id m20csp1281644imm; Fri, 27 Apr 2018 16:34:37 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqtA5RAaK+T3yM5Q3mHxE49x9qO9Qs6pOvWA7B5D+d/83Yy8v4hlDtBTgrtLThUJc8QQ0rD X-Received: by 2002:a17:902:6b09:: with SMTP id o9-v6mr4111657plk.256.1524872077159; Fri, 27 Apr 2018 16:34:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524872077; cv=none; d=google.com; s=arc-20160816; b=hgRN89ALUUPax37oO9kL7w/SGZlso5gux0dhUD1aOEnLtm1GxwjA8O2Hn4XhZRC7r+ F8cSleKPYKaKHzuOfnOvQsX0lI5HgKsFGKfeMDAM2lSUpaC1C8ffqYjwkSoEMl4U5lgv Q6rWqzYtmk1FQho+DYctvDUmKUJvPJS4TJzCI2RvPaiWAcjgqPoXjokOACWYT2bZ3sS7 DNugKwYH38QZgF1g2X/MUPLH7DShnzf6czEodSdRnH5ww10H7mqKLj6J0M9QL2zbbFXI CDHkCBI1HJymImcf59AH2qpS8sc7EsXjDbGXxhGGif3vpstsXNbP7ERalqNgxoFe5ju0 ae0w== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject:arc-authentication-results; bh=D4bH8JsqPD/VJQSyVJT+wqGoaRkRSiyM3rt3yH7uRtc=; b=MfiCPK9QQdPKRb/G2RVdRVp7QIL5DQ2Cz5NWmy+cZY8Rnat2fpjm9Rh3qnvaCPs9Pf uegQ3FxcHFDuMHb1ff3RtDLDH7okObV+h2bp7ex+HpzxGg3bhq9sng+VoLTv/gWmJrEu OImCI1rNf0cFAfxQpTagdLK1jo7r8/4lnBPnqyI+cibhnE2LytretPhIp2ekdGmWBXpB WzfRYCOQUWjWLTGyMONaFSQ1zH65ax+AJq/a3tGLmDcdliUpl1yOk5puz3ors9JSF+lQ P5TAaWUkMAN4qqeCJcS+QSrOafEuah/8SPtlhqqubEV47xdYipgs3HmWuEsQ33YTo4f6 /Gnw== 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 i35-v6si2123073plg.504.2018.04.27.16.34.23; Fri, 27 Apr 2018 16:34:37 -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 S933090AbeD0XdT (ORCPT + 99 others); Fri, 27 Apr 2018 19:33:19 -0400 Received: from www62.your-server.de ([213.133.104.62]:48071 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932444AbeD0XdS (ORCPT ); Fri, 27 Apr 2018 19:33:18 -0400 Received: from [62.202.221.10] (helo=linux.home) by www62.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.85_2) (envelope-from ) id 1fCCrc-00084W-F5; Sat, 28 Apr 2018 01:33:16 +0200 Subject: Re: [PATCH] bpf: fix misaligned access for BPF_PROG_TYPE_PERF_EVENT program type on x86_32 platform To: Alexei Starovoitov , Wang YanQing , ast@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <20180426095749.GA29207@udknight> <20180427224854.2g7ximim7nwkgdpd@ast-mbp> From: Daniel Borkmann Message-ID: Date: Sat, 28 Apr 2018 01:33:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20180427224854.2g7ximim7nwkgdpd@ast-mbp> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.99.3/24519/Fri Apr 27 22:27:55 2018) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/28/2018 12:48 AM, Alexei Starovoitov wrote: > On Thu, Apr 26, 2018 at 05:57:49PM +0800, Wang YanQing wrote: >> All the testcases for BPF_PROG_TYPE_PERF_EVENT program type in >> test_verifier(kselftest) report below errors on x86_32: >> " >> 172/p unpriv: spill/fill of different pointers ldx FAIL >> Unexpected error message! >> 0: (bf) r6 = r10 >> 1: (07) r6 += -8 >> 2: (15) if r1 == 0x0 goto pc+3 >> R1=ctx(id=0,off=0,imm=0) R6=fp-8,call_-1 R10=fp0,call_-1 >> 3: (bf) r2 = r10 >> 4: (07) r2 += -76 >> 5: (7b) *(u64 *)(r6 +0) = r2 >> 6: (55) if r1 != 0x0 goto pc+1 >> R1=ctx(id=0,off=0,imm=0) R2=fp-76,call_-1 R6=fp-8,call_-1 R10=fp0,call_-1 fp-8=fp >> 7: (7b) *(u64 *)(r6 +0) = r1 >> 8: (79) r1 = *(u64 *)(r6 +0) >> 9: (79) r1 = *(u64 *)(r1 +68) >> invalid bpf_context access off=68 size=8 >> >> 378/p check bpf_perf_event_data->sample_period byte load permitted FAIL >> Failed to load prog 'Permission denied'! >> 0: (b7) r0 = 0 >> 1: (71) r0 = *(u8 *)(r1 +68) >> invalid bpf_context access off=68 size=1 >> >> 379/p check bpf_perf_event_data->sample_period half load permitted FAIL >> Failed to load prog 'Permission denied'! >> 0: (b7) r0 = 0 >> 1: (69) r0 = *(u16 *)(r1 +68) >> invalid bpf_context access off=68 size=2 >> >> 380/p check bpf_perf_event_data->sample_period word load permitted FAIL >> Failed to load prog 'Permission denied'! >> 0: (b7) r0 = 0 >> 1: (61) r0 = *(u32 *)(r1 +68) >> invalid bpf_context access off=68 size=4 >> >> 381/p check bpf_perf_event_data->sample_period dword load permitted FAIL >> Failed to load prog 'Permission denied'! >> 0: (b7) r0 = 0 >> 1: (79) r0 = *(u64 *)(r1 +68) >> invalid bpf_context access off=68 size=8 >> " >> >> This patch fix it, the fix isn't only necessary for x86_32, it will fix the >> same problem for other platforms too, if their size of bpf_user_pt_regs_t >> can't divide exactly into 8. >> >> Signed-off-by: Wang YanQing >> --- >> Hi all! >> After mainline accept this patch, then we need to submit a sync patch >> to update the tools/include/uapi/linux/bpf_perf_event.h. >> >> Thanks. >> >> include/uapi/linux/bpf_perf_event.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/include/uapi/linux/bpf_perf_event.h b/include/uapi/linux/bpf_perf_event.h >> index eb1b9d2..ff4c092 100644 >> --- a/include/uapi/linux/bpf_perf_event.h >> +++ b/include/uapi/linux/bpf_perf_event.h >> @@ -12,7 +12,7 @@ >> >> struct bpf_perf_event_data { >> bpf_user_pt_regs_t regs; >> - __u64 sample_period; >> + __u64 sample_period __attribute__((aligned(8))); > > I don't think this necessary. > imo it's a bug in pe_prog_is_valid_access > that should have allowed 8-byte access to 4-byte aligned sample_period. > The access rewritten by pe_prog_convert_ctx_access anyway, > no alignment issues as far as I can see. Right, good point. Wang, could you give the below a test run: diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c index 56ba0f2..95b9142 100644 --- a/kernel/trace/bpf_trace.c +++ b/kernel/trace/bpf_trace.c @@ -833,8 +833,14 @@ static bool pe_prog_is_valid_access(int off, int size, enum bpf_access_type type return false; if (type != BPF_READ) return false; - if (off % size != 0) - return false; + if (off % size != 0) { + if (sizeof(long) != 4) + return false; + if (size != 8) + return false; + if (off % size != 4) + return false; + } switch (off) { case bpf_ctx_range(struct bpf_perf_event_data, sample_period):