From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 7C49B24B24E for ; Fri, 10 Jan 2025 23:27:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736551642; cv=none; b=lVsyoGBOaF1v9l9hSF2+LHZkAFm/QvqiPkn7+l0SbKkoBrnH5TXlEVQOGduSg3fnEyMHaOhw5uKiG2m8PDN2ayK2wDETVQ7n99uofvccnXRMtoxwrZnI/TDKYUGVwyySWJVebvRnf++HTwpepXmo0VpUEZWKHcmZUduI+cvsP1E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736551642; c=relaxed/simple; bh=Y3I78nuG/+Sio+fd77xDTy2Z7weF37r2M4C230az/WY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=LiNGi8TELRiySdz5MesueoxSe7sS2VUU3VFWmF617eHgu/bY7e/3bubpZRQRTvvnate3P0+7kOjrlZ+5rw8RgOUqTeq22Ur2HLajINb7kUujTqMFmlSyX+wgMEmrhxvylHFHAoy4RVgeLRkqsGERb/rssnC3zlFvdAoo+Hnq1nc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=adb4BO2+; arc=none smtp.client-ip=13.77.154.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="adb4BO2+" Received: from narnia (unknown [167.220.2.28]) by linux.microsoft.com (Postfix) with ESMTPSA id 8774B203D5F3; Fri, 10 Jan 2025 15:27:16 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 8774B203D5F3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1736551641; bh=Y3I78nuG/+Sio+fd77xDTy2Z7weF37r2M4C230az/WY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=adb4BO2+EAyCwUVQlLDI8ZW32DtZ4SKEkRE1zY7Z3D9d+dbUw0pRsw/J21bZPSTgT 6ayt+A8fKlZnCTIHj9nPi2xQ4P/QTnYsIOMV9ckOPkwpdLZoah2E940vyyYrFh8VEN cH32kp165UEFPPCzrK252QSbFzV+K1cbQFcbZG3o= From: Blaise Boscaccy To: Alexei Starovoitov Cc: bpf , nkapron@google.com, Matteo Croce , Roberto Sassu , Greg Kroah-Hartman , Paul Moore , code@tyhicks.com, Francis Laniel , Daniel Borkmann , John Fastabend Subject: Re: [POC][RFC][PATCH] bpf: in-kernel bpf relocations on raw elf files In-Reply-To: References: <20250109214617.485144-1-bboscaccy@linux.microsoft.com> Date: Fri, 10 Jan 2025 15:27:13 -0800 Message-ID: <87ikqm45da.fsf@microsoft.com> Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Alexei Starovoitov writes: > On Thu, Jan 9, 2025 at 1:47=E2=80=AFPM Blaise Boscaccy > wrote: >> >> >> This is a proof-of-concept, based off of bpf-next-6.13. The >> implementation will need additional work. The goal of this prototype was >> to be able load raw elf object files directly into the kernel and have >> the kernel perform all the necessary instruction rewriting and >> relocation calculations. Having a file descriptor tied to a bpf program >> allowed us to have tighter integration with the existing LSM >> infrastructure. Additionally, it opens the door for signature and proven= ance >> checking, along with loading programs without a functioning userspace. >> >> The main goal of this RFC is to get some feedback on the overall >> approach and feasibility of this design. > > It's not feasible. > > libbpf.a is mainly a loader of bpf ELF files. > There is a specific format of ELF files, a convention on section names, > a protocol between LLVM and libbpf, etc. > These things are stable api from libbpf 1.x pov. > There is a chance that they will change in libbpf 2.x. > There are no plans to do so now, but because it's all user space > there is room for changes. > The kernel doesn't have such luxury. > Hence we cannot copy paste libbpf into the kernel and make > it parse the same ELF data, since it will force us to support > this exact format forever. > Hence the design is not feasible. > Noted.=20=20 > This was discussed multiple times on the list and at LSFMMBPF, LPC > conferences over the years. > > But if the real goal of these patches to: > >> open the door for signature and provenance >> checking, along with loading programs without a functioning userspace. > > then please take a look at the light skeleton. > There is an existing mechanism to load bpf ELF files without libbpf > and without user space. > Search for 'bpftool gen skeleton -L'. Our goal is to have verifiable ebpf programs that are portable across multiple kernels. I looked into light skels, it appears that all the instruction relocations are calculated during skeleton generation and a static instruction buffer containing those fixed relocation results is passed into the kernel? For some relocs, those values would be deterministic, making that a non-issue. For others that rely on btf data or kernel symbols those might not be portable anymore. Would it be amenable to possibly alter the light skeleton generation code to pass btf and some other metadata into the kernel along with instructions or are you trying to avoid any sort of fixed dependencies on anything in the kernel other than the bpf instrucion set itself? -blaise > > Also there were prototype patches to add signature checking on > top of the light skeleton, > and long discussions on the list and conferences about 'gate keeper' conc= ept.