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 A0CBE2367BC; Sat, 12 Apr 2025 14:11:12 +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=1744467074; cv=none; b=W7BH6fFZOgcfNbI1ndf/3zugZ6EhMUopAgK/C2X1aSFcFm0E2nAhzAJOiyviArFV+FoQsAwvSIJzDXMEaV+Hf5j4m06fmXLGi+oE0d3VtFzi7nB0o8zKvqLlzsdhiZgWvRIDcsgLw9qCoOPNgA8PmOHFJQeIKI41XdcL8JE9wqI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744467074; c=relaxed/simple; bh=6UupgWJqX74K4rb42t9zk7pR4gsrJNFwzwL4a7gqYCw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=QuxKJC1Xd2yQsgMJrPOGmEo9tG5LWJvaXQiBz0b04jfWf0tyf6x7Y+LPP37ST3J3BCD9f4IlrPUll69/aBq7MkLvk+l66OCoLF7p2Cf1kggENjqnYyjafcl3Cm/QyxNruWpyIcRpfU+BD0vrko2iw4+IEJX/1cEOCGspRZZPnmo= 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=RRMoS31T; 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="RRMoS31T" Received: from narnia (unknown [167.220.2.28]) by linux.microsoft.com (Postfix) with ESMTPSA id 7A2A321165B8; Sat, 12 Apr 2025 07:11:04 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 7A2A321165B8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1744467072; bh=pTnd2Oc8i8/ma8A52qza9zwPziCRMHwOGThxeMcufiE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=RRMoS31T422OQGTx+ALxBabnWUobD2SGOF9kKhtax/Q9kNBsnMTF30iIo6s62oUcd 9hayyqT4XBOzTiMuXmDqpBpb3kjYL34C0pagTkdwl+BsCNobtK8HIYmwSTpnWM72sc 7MbXa9/e4EXJcrbLuqpTIOI03a2CVhMn3o5hgH1k= From: Blaise Boscaccy To: Alexei Starovoitov , Matteo Croce Cc: Jonathan Corbet , David Howells , Herbert Xu , "David S. Miller" , Paul Moore , James Morris , "Serge E. Hallyn" , Masahiro Yamada , Nathan Chancellor , Nicolas Schier , Shuah Khan , =?utf-8?Q?Mick?= =?utf-8?Q?a=C3=ABl_Sala=C3=BCn?= , =?utf-8?Q?G=C3=BCnther?= Noack , Nick Desaulniers , Bill Wendling , Justin Stitt , Jarkko Sakkinen , Jan Stancek , Neal Gompa , "open list:DOCUMENTATION" , LKML , keyrings@vger.kernel.org, Linux Crypto Mailing List , LSM List , Linux Kbuild mailing list , "open list:KERNEL SELFTEST FRAMEWORK" , bpf , clang-built-linux , nkapron@google.com, Matteo Croce , Roberto Sassu , Cong Wang Subject: Re: [PATCH v2 security-next 1/4] security: Hornet LSM In-Reply-To: References: <20250404215527.1563146-1-bboscaccy@linux.microsoft.com> <20250404215527.1563146-2-bboscaccy@linux.microsoft.com> Date: Sat, 12 Apr 2025 07:11:01 -0700 Message-ID: <87plhhjwqy.fsf@microsoft.com> Precedence: bulk X-Mailing-List: linux-doc@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 Fri, Apr 11, 2025 at 5:30=E2=80=AFPM Matteo Croce wrote: >> >> Il giorno sab 12 apr 2025 alle ore 02:19 Alexei Starovoitov >> ha scritto: >> >> Similar to what I proposed here? >> >> https://lore.kernel.org/bpf/20211203191844.69709-2-mcroce@linux.microsof= t.com/ > ... >> @@ -1346,6 +1346,8 @@ union bpf_attr { >> __aligned_u64 fd_array; /* array of FDs */ >> __aligned_u64 core_relos; >> __u32 core_relo_rec_size; /* sizeof(struct bpf_core_relo) */ >> + __aligned_u64 signature; /* instruction's signature */ >> + __u32 sig_len; /* signature size */ > > Well, yeah, two fields are obvious. > But not like that link from 2021. > KP proposed them a year later in 2022 on top of lskel > which was much closer to be acceptable. > We need to think it through and complete the work, > since there are various ways to do it. > For example, lskel has a map and a prog. > A signature in a prog may cover both, but > not necessary it's a good design. > A signature for the map plus a signature for the prog > that is tied to a map might be a better option. > At map creation time the contents can be checked, > the map is frozen, and then the verifier can proceed > with prog's signature checking. > lskel doesn't support all the bpf feature yet, so we need > to make sure that the signature verification process > is extensible when lskel gains new features. > > Attaching was also brought up at lsfmm. > Without checking the attach point the whole thing is quite > questionable from security pov. That statement is quite questionable. Yes, IIRC you brought that up. And again, runtime policy enforcement has nothing to do with proving code provenance. They are completely independent concerns. That would be akin to saying that having locks on a door is questionable without having surveillance cameras installed.