From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f173.google.com (mail-pg1-f173.google.com [209.85.215.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D84FF43AB0 for ; Thu, 16 Jul 2026 00:12:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784160774; cv=none; b=Y+AhfpjJeXEWoT7pINNJwi9RYLlzwuXmVBG46OSHQwcqq9HUu+z4jo0d0h/VuSkCeDkoREHFbj+n6qK0ILjJ6Vx82MKt1miofKW3qnJ7IHWr1JlnMdmDitSKFxho+oH6vvrVgsUf4bkEQjMC53CF7geOeFiNhIgAgDs4EhSXbVs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784160774; c=relaxed/simple; bh=FZPGY9KYrMtOTNqPRwUkPHORLOYpJ6tk1GVDc+iL/yc=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=kWiIhQ9+g5k+9YZ/eBB/Vp9bU3iKP+FuOJREQ7sPkSou4THO7a7vxPq4WF6icCb62O7BWkQiGNgkPSVE91p/nA8eIPVjrWrRbrjQXgtXKfgglW1gOKxj8V+E/l1YL8uWHm74Lru6rXZxKMwK1FA5jE5YuSMYCxg5I6hqApRGGEA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=MvSaKW5E; arc=none smtp.client-ip=209.85.215.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="MvSaKW5E" Received: by mail-pg1-f173.google.com with SMTP id 41be03b00d2f7-c89636920a3so1596489a12.1 for ; Wed, 15 Jul 2026 17:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784160772; x=1784765572; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=Yqp9M8SmLPe+XpZ6WaehY4883xFTw01pffMOJV97erU=; b=MvSaKW5EK7Vtl87mdOX32EMKmP+7XPQSKQLftRYH2Kfn+V2EakzqrZwF43Gt07LcO8 a2Wh932u01JACFY4q7W1cRNN+RlDm7cniR+Gs1GT/mRMmH13ejjwMUmg1GOPIWJUGhZa 0VG+VLJBNmUaTknpzBS0Ximj5sPWalFMapzuCuGYpBPGlle3MDgLp1ZqC2/jtM0PY1yR AxY0DIHpg528ij8y3Q4i4wHy2KNHLlBOsMblilakK9iaUlb/AvBQOOcNhA7w38rG3/pm 1jtJ9pu9n/p3TZEHFXjnPrBnjyY57MYUhox+72yZ4I8TvKVc4F9CvVPhX8gJUZjkIau7 KqXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784160772; x=1784765572; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Yqp9M8SmLPe+XpZ6WaehY4883xFTw01pffMOJV97erU=; b=eywBP+Q5xGb5wzm6RC3r+Nwz5dO7g1Ls4hvA22Yq5GiQcwHP5MwMUx17nkLUNcpcMm xIvpbF6/3RNyiWbf3IZV5pNntV6+6fbLi6BjvHH6PirOR8SlUsvY62bl3MXD0fpv5PcX eRBK560XEH9VTjWHo0KrRL6S0VPRuFNpbGi7xQri3TJSbnOY3QbFCJVlWFDMLiYvIoya 1LXM+hFM+dexX8YjH5QEypQQ/TAt8HRiEK4JkYrjsvnEyBnfRJdkmLd+B15SQzedvWOn vSTTMssOzGDiI4BsUfZbWiRiTSY2ceZDOO3mrDXJ0EB0cIZEy073rsiGlt8fKkpLoJ/t Ll3A== X-Forwarded-Encrypted: i=1; AHgh+Rp+DtlYaXroiL9dCdf5cZuJKGtOPtO68l/jKEVlZ/N9z+/oxh49AyoguZ6VAOriU1kFnBMyYpaUEjo7C+wE@vger.kernel.org X-Gm-Message-State: AOJu0YzVeDYzmXk4T6JAtz8V7g+7cTfxFoI98Xa5xNic7p5Z4UxSh705 IThBsjZ8L1iw+pwjPjB1ZFCh7hQ6REGoN7b8ksxAq3s2RQIZaWCDXlnj X-Gm-Gg: AfdE7cn7OOBP2ot1paWNeB9tic45G57CTdjsgFfnOtr7TVxemcRNhV4EBhogJuXptPb iF6t0ZqDY1S8hb4N/TgHLUpp2GUAuspi/gi8jHCrMGztOSs9/VciEuXF0PxqeQCP6fyBUXZA23J lERX0/lmNWnLR8EB3vZhogZn2bgz1fVPnGg6fNtraVGkXlLbJmiS8G4u510aGmH321yxCeaeLEg 4U/O2Er0ZFuO/RNG0Ebt/KmTm4PZf1Z4ggwxSj/2MJCf3KNnvzSbRuUXuc68yRz/lMtxgVSRa5u 70HVAO7BVZoxjqqRCiMw7bSeg78YaabYemzKq7LYXHP1xGiR2maGbpECVYbehEGkUjnBcoR2DdR cdqxzawMKjlN6TvBWeQdv3DNZMGo0fxt82Xs+LI7SlxL0CnKrrk9FE6J0Cv6sNWpigawhkMb2U7 NESdfOeo80A/MkvQ== X-Received: by 2002:a05:6a21:1309:b0:3b4:b24e:27b4 with SMTP id adf61e73a8af0-3c11077668bmr21904263637.1.1784160771979; Wed, 15 Jul 2026 17:12:51 -0700 (PDT) Received: from localhost ([98.35.8.117]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-13cd4359166sm4828005c88.14.2026.07.15.17.12.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Jul 2026 17:12:51 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 15 Jul 2026 17:12:49 -0700 Message-Id: Cc: "Daniel Borkmann" , "Alexei Starovoitov" , "Kees Cook" , "Alexander Viro" , "Jan Kara" , "Jonathan Corbet" , , , , , Subject: Re: [PATCH v2 0/9] binfmt_misc: bpf-backed binary type handlers From: "Farid Zakaria" To: "Farid Zakaria" , "Christian Brauner" X-Mailer: aerc 0.21.0 References: <20260714-work-bpf-binfmt_misc-v2-0-57b7529c002c@kernel.org> <178407531866.2243172.12944140194021045628.b4-review@b4> <20260715-reorganisation-umtausch-radiergummi-8b38ca81ebb0@brauner> In-Reply-To: On Wed Jul 15, 2026 at 5:10 PM PDT, Farid Zakaria wrote: > On Wed Jul 15, 2026 at 1:40 AM PDT, Christian Brauner wrote: >> On 2026-07-14 17:28 -0700, Farid Zakaria wrote: >>> On Tue, 14 Jul 2026 21:58:05 +0200, Christian Brauner wrote: >>> > [...] >>> > .load =3D (void *)nix_load, >>> > .name =3D "nix", >>> > }; >>> >=20 >>> > Farid, this should slot underneath your qemu demo from [4] with the >>> > program ported to struct_ops. Feel free to take it from here. >>>=20 >>> Thanks for the recent update. >>> Is it still "take it from here" or was this left-over from the previous >>> series. >> >> Leftover from the previous series. :) Sorry. >> > > No problem -- just checking. > >>> I think you've done the majority of the work here with the validation o= f >>> the few selftests and mentioning the gap for shebangs. >> >> It was a nice joint effort imo. I think this is in general an >> interesting idea. I'm also working on some glibc loader patches. One >> of the patches in this series allows for "transparent binary execution" >> if the loader supports it. >> >> In this mode you can pass AT_EXECFD to an interpreter and don't change >> the command line. An exec like this is indistinguishable from a "native" >> exec. >> > > This sounds super interesting (orthogonal to binfmt_misc and BPF work rig= ht?) > but a neat feature nonetheless. I wonder if this makes it easier for > tools like perf to attribute the correct binary or they have already > handled interpreters in the cmdline well enough. > >>> Please let me know what you would like me to do next. I just tested >>> reviewing the series with b4 + AI -- pretty cool. Was a little clunky t= o >>> get it to work but overall a good experience. (I need to tinker with it >>> a little for NixOS vim setup etc..) >>>=20 >>> I shared this patch series at my workplace as well.=20 >>> I think there is some interest in the work. >>> (If you are curious as to why, I can elaborate on that as well). >> >> Sure, happy to hear other use-cases. I have a plan to make it possible >> to pre-open a set of interpreters (pin them essentially) when >> registering the handler in binfmt_misc and then bpf would be able to >> select from a set of pre-opened interpreters but that's for the future. >> > > This is assuming that in prior calls to the BPF it returned the path > string to be pinned? > > As for the use case, we use buck2 -- > a build system similar to Google's Bazel and does many things in spirit > to Nix by leveraging RUN_PATH to create links to the shared-libraries. > > We have customized our interpreter however the lack of $ORIGIN means > that we've had to maintain a single glibc versioning across our machines = as > a platform since glibc has tight coupling between the loader and the > libc. > > This has been a pain point for upgrading. I think the ability for the > loader to now be relative to $ORIGIN meanst hat each binary could > diverge glibc/ld.so and not affect the rest of the machines. > > tl;dr; ld.so from $ORIGIN itself is not only useful but since it's > intimately tied to glibc, it allows for more flexibililty across our > builds (very similar to NixOS in spirit). > >>> I hope you are enjoying your vacation. >> >> Thanks! Ah one more thing! What's next for this patch? Do we wait for BPF maintainers to comment? Should I continue to add Reviewed-By trailers to the other patches? (I have limited knowledge on some of the mutex stuff but the agent review in b4 was helpful in understanding it enough to give a review.) Sorry if it's obvious. I've never contributed to a patch this far along or substantial to the point of having to understand the merging/acceptance process in Linux.