From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932601AbdKFPz4 convert rfc822-to-8bit (ORCPT ); Mon, 6 Nov 2017 10:55:56 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:41724 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752864AbdKFPzx (ORCPT ); Mon, 6 Nov 2017 10:55:53 -0500 Date: Mon, 06 Nov 2017 21:25:41 +0530 From: "Naveen N. Rao" Subject: Re: [RFC PATCH] bpf: Add helpers to read useful task_struct members To: Alexei Starovoitov , netdev@vger.kernel.org, Sandipan Das Cc: Brendan Gregg , daniel@iogearbox.net, Martin KaFai Lau , Kees Cook , linux-kernel@vger.kernel.org References: <20171103065833.8076-1-sandipan@linux.vnet.ibm.com> <94a4761f-1b51-8b70-fb7f-3cea91c69717@fb.com> <1509815348.8zu63uatdo.naveen@linux.ibm.com> <4acdc081-341d-ee91-a591-b1d331a8c8d5@fb.com> In-Reply-To: <4acdc081-341d-ee91-a591-b1d331a8c8d5@fb.com> User-Agent: astroid/0.10.2 (https://github.com/astroidmail/astroid) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT X-TM-AS-GCONF: 00 x-cbid: 17110615-0016-0000-0000-000004FE17E0 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17110615-0017-0000-0000-00002839B389 Message-Id: <1509982000.092la4257a.naveen@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-11-06_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711060220 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Alexei Starovoitov wrote: > On 11/5/17 2:31 AM, Naveen N. Rao wrote: >> Hi Alexei, >> >> Alexei Starovoitov wrote: >>> On 11/3/17 3:58 PM, Sandipan Das wrote: >>>> For added security, the layout of some structures can be >>>> randomized by enabling CONFIG_GCC_PLUGIN_RANDSTRUCT. One >>>> such structure is task_struct. To build BPF programs, we >>>> use Clang which does not support this feature. So, if we >>>> attempt to read a field of a structure with a randomized >>>> layout within a BPF program, we do not get the expected >>>> value because of incorrect offsets. To observe this, it >>>> is not mandatory to have CONFIG_GCC_PLUGIN_RANDSTRUCT >>>> enabled because the structure annotations/members added >>>> for this purpose are enough to cause this. So, all kernel >>>> builds are affected. >>>> ... >>>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h >>>> index f90860d1f897..324508d27bd2 100644 >>>> --- a/include/uapi/linux/bpf.h >>>> +++ b/include/uapi/linux/bpf.h >>>> @@ -338,6 +338,16 @@ union bpf_attr { >>>> * @skb: pointer to skb >>>> * Return: classid if != 0 >>>> * >>>> + * u64 bpf_get_task_pid_tgid(struct task_struct *task) >>>> + * Return: task->tgid << 32 | task->pid >>>> + * >>>> + * int bpf_get_task_comm(struct task_struct *task) >>>> + * Stores task->comm into buf >>>> + * Return: 0 on success or negative error >>>> + * >>>> + * u32 bpf_get_task_flags(struct task_struct *task) >>>> + * Return: task->flags >>>> + * >>> >>> I don't think it's a solution. >>> Tracing scripts read other fields too. >>> Making it work for these 3 fields is a drop in a bucket. >> >> Indeed. However... >> >>> If randomization is used I think we have to accept >>> that existing bpf scripts won't be usable. >> >> ... the actual issue is that randomization isn't necessary for this to >> show up. The annotations added to mark off the structure members results >> in some structure members being moved into an anonymous structure, which >> would then get padded differently. So, *all* kernels since v4.13 are >> affected, afaict. > > hmm. why would all 4.13+ be affected? > It's just an anonymous struct inside task_struct. > Are you saying that due to clang not adding this 'struct { };' treatment > to task_struct? Yes, that's what it looked like. > I thought such struct shouldn't change layout. > If it is we need to fix include/linux/compiler-clang.h to do that > anon struct as well. We considered that, but it looked to be very dependent on the version of gcc used to build the kernel. But, this may be a simpler approach for the shorter term. > >> As such, we wanted to propose this as a short term solution, but I do >> agree that this doesn't solve the real issue. >> >>> Long term solution is to support 'BPF Type Format' or BTF >>> (which is old C-Type Format) for kernel data structures, >>> so bcc scripts wouldn't need to use kernel headers and clang. >>> The proper offsets will be described in BTF. >>> We were planning to use it initially to describe map key/value, >>> but it applies for this case as well. >>> There will be a tool that will take dwarf from vmlinux and >>> compress it into BTF. Kernel will also be able to verify >>> that BTF is a valid BTF. >> >> This is the first that I've heard about BTF. Can you share more details >> about it, or point me to some place where it has been discussed? >> >> We considered having tools derive the structure offsets from debuginfo, >> but debuginfo may not always be present on production systems. So, it >> isn't clear if having that dependency is fine. I'm not sure how BTF will >> be different. > > It was discussed at this year plumbers: > https://lwn.net/Articles/734453/ > > btw the name BTF is work in progress. We started with CTF, but > it conflicts with all other meanings of this abbreviation. > Likely we will call it something different at the end. > > Initial goal was to describe key/map values of bpf maps to > make debugging easier, but now we want to use this compressed > type format for tracing as well, since installing kernel headers > everywhere doesn't scale well while CTF can be embedded in vmlinux Makes sense, though I'm curious on how you're planning to have this work without the kernel headers :) > > We were also thinking to improve verifier with CTF knowledge too. > Like if CTF describes that map value is two u32, but bpf program > is doing 8-byte access then something is wrong and either warn > or reject such program. Sounds good. I look forward to more details/patches on this front once you're ready to share more. Thanks, - Naveen