From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752282AbbJ0D0h (ORCPT ); Mon, 26 Oct 2015 23:26:37 -0400 Received: from mail-pa0-f42.google.com ([209.85.220.42]:34106 "EHLO mail-pa0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751573AbbJ0D0g (ORCPT ); Mon, 26 Oct 2015 23:26:36 -0400 Date: Mon, 26 Oct 2015 20:26:30 -0700 From: Alexei Starovoitov To: Wang Nan Cc: acme@kernel.org, ast@kernel.org, linux-kernel@vger.kernel.org, pi3orama@163.com, lizefan@huawei.com, Arnaldo Carvalho de Melo , "David S. Miller" , Wu Fengguang Subject: Re: [net-next PATCHv2] bpf: Output error message to logbuf when loading failure Message-ID: <20151027032628.GB26748@Alexeis-MacBook-Pro.local> References: <1445841394-142865-1-git-send-email-wangnan0@huawei.com> <1445843588-143137-1-git-send-email-wangnan0@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1445843588-143137-1-git-send-email-wangnan0@huawei.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 26, 2015 at 07:13:08AM +0000, Wang Nan wrote: > Many reasons can make bpf_prog_load() return EINVAL. This patch utilizes > logbuf to deliver the actual reason of the failure. > > Without this patch, it is very easy for user to pass an object with > "version" section not match the kernel version code, and the problem > is hard to determine from return code (EINVAL). > > Signed-off-by: Wang Nan > Cc: Alexei Starovoitov > Cc: Arnaldo Carvalho de Melo > Cc: David S. Miller > Cc: Wu Fengguang NACK for both implementation and design. > + /* Don't need care the copying result too much */ > + WARN(copy_to_user(log_ubuf, log_buf, log_size), > + KERN_WARNING "Failed to copy BPF error note '%s' to log buffer\n", > + log_buf); unprivilged user will be spamming kernel logs?! > - if (attr->insn_cnt >= BPF_MAXINSNS) > + if (attr->insn_cnt >= BPF_MAXINSNS) { > + bpf_prog_load_note(attr, "Too many instructions: %d > %d\n", > + attr->insn_cnt, BPF_MAXINSNS); > return -EINVAL; if user space did that, it's wrong and can detect it on its own. > if (type == BPF_PROG_TYPE_KPROBE && > - attr->kern_version != LINUX_VERSION_CODE) > + attr->kern_version != LINUX_VERSION_CODE) { > + bpf_prog_load_note(attr, > + "Kernel version mismatch: 0x%x != 0x%x\n", > + attr->kern_version, LINUX_VERSION_CODE); > return -EINVAL; user space (perf) could have checked that on its own without kernel changes. > /* find program type: socket_filter vs tracing_filter */ > err = find_prog_type(type, prog); > - if (err < 0) > + if (err < 0) { > + bpf_prog_load_note(attr, "Invalid program type: %d\n", type); > goto free_prog; same here. In general syscalls muxing different error conditions into EINVAL is a kernel wide problem and should be solved for all.