Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751923AbdH1Dtr (ORCPT ); Sun, 27 Aug 2017 23:49:47 -0400 Received: from namei.org ([65.99.196.166]:54267 "EHLO namei.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751726AbdH1Dtp (ORCPT ); Sun, 27 Aug 2017 23:49:45 -0400 Date: Mon, 28 Aug 2017 13:48:41 +1000 (AEST) From: James Morris To: =?ISO-8859-15?Q?Micka=EBl_Sala=FCn?= cc: Alexei Starovoitov , linux-kernel@vger.kernel.org, Alexei Starovoitov , Andy Lutomirski , Arnaldo Carvalho de Melo , Casey Schaufler , Daniel Borkmann , David Drysdale , "David S . Miller" , "Eric W . Biederman" , James Morris , Jann Horn , Jonathan Corbet , Matthew Garrett , Michael Kerrisk , Kees Cook , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Shuah Khan , Tejun Heo , Thomas Graf , Will Drewry , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-security-module@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [kernel-hardening] Re: [PATCH net-next v7 02/10] bpf: Add eBPF program subtype and is_valid_subtype() verifier In-Reply-To: <607ceb21-5aa5-678b-4438-0d8dcb69fc3c@digikod.net> Message-ID: References: <20170821000933.13024-1-mic@digikod.net> <20170821000933.13024-3-mic@digikod.net> <20170823024452.zvizovwfd7xjucsx@ast-mbp> <607ceb21-5aa5-678b-4438-0d8dcb69fc3c@digikod.net> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="1665246916-1251487109-1503892121=:8842" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1900 Lines: 43 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1665246916-1251487109-1503892121=:8842 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8BIT On Wed, 23 Aug 2017, Micka?l Sala?n wrote: > >> + struct { > >> + __u32 abi; /* minimal ABI version, cf. user doc */ > > > > the concept of abi (version) sounds a bit weird to me. > > Why bother with it at all? > > Once the first set of patches lands the kernel as whole will have landlock feature > > with a set of helpers, actions, event types. > > Some future patches will extend the landlock feature step by step. > > This abi concept assumes that anyone who adds new helper would need > > to keep incrementing this 'abi'. What value does it give to user or to kernel? > > The users will already know that landlock is present in kernel 4.14 or whatever > > and the kernel 4.18 has more landlock features. Why bother with extra abi number? > > That's right for helpers and context fields, but we can't check the use > of one field's content. The status field is intended to be a bitfield > extendable in the future. For example, one use case is to set a flag to > inform the eBPF program that it was already called with the same context > and can skip most of its check (if not related to maps). Same goes for > the FS action bitfield, one may want to add more of them. Another > example may be the check for abilities. We may want to relax/remove the > capability require to set one of them. With an ABI version, the user can > easily check if the current kernel support that. Don't call it an ABI, perhaps minimum policy version (similar to what SELinux does). Changes need to be made so that any existing userspace still works. -- James Morris --1665246916-1251487109-1503892121=:8842--