From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764266AbcINXXx (ORCPT ); Wed, 14 Sep 2016 19:23:53 -0400 Received: from smtp-sh2.infomaniak.ch ([128.65.195.6]:55268 "EHLO smtp-sh2.infomaniak.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1763607AbcINXXu (ORCPT ); Wed, 14 Sep 2016 19:23:50 -0400 Subject: Re: [RFC v3 03/22] bpf,landlock: Add a new arraymap type to deal with (Landlock) handles To: Alexei Starovoitov References: <20160914072415.26021-1-mic@digikod.net> <20160914072415.26021-4-mic@digikod.net> <20160914185157.GA53542@ast-mbp.thefacebook.com> Cc: linux-kernel@vger.kernel.org, Alexei Starovoitov , Andy Lutomirski , Arnd Bergmann , Casey Schaufler , Daniel Borkmann , Daniel Mack , David Drysdale , "David S . Miller" , Elena Reshetova , "Eric W . Biederman" , James Morris , Kees Cook , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Tejun Heo , Will Drewry , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-security-module@vger.kernel.org, netdev@vger.kernel.org, cgroups@vger.kernel.org From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= Message-ID: <57D9DBC9.2010605@digikod.net> Date: Thu, 15 Sep 2016 01:22:49 +0200 User-Agent: MIME-Version: 1.0 In-Reply-To: <20160914185157.GA53542@ast-mbp.thefacebook.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UPGkAw2AHu1mFktC0wkiPFcXM1xMapqCd" X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UPGkAw2AHu1mFktC0wkiPFcXM1xMapqCd Content-Type: multipart/mixed; boundary="kGu4VJSvr7M189NUoiXHrVNXfHAD1iXGI"; protected-headers="v1" From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= To: Alexei Starovoitov Cc: linux-kernel@vger.kernel.org, Alexei Starovoitov , Andy Lutomirski , Arnd Bergmann , Casey Schaufler , Daniel Borkmann , Daniel Mack , David Drysdale , "David S . Miller" , Elena Reshetova , "Eric W . Biederman" , James Morris , Kees Cook , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Tejun Heo , Will Drewry , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-security-module@vger.kernel.org, netdev@vger.kernel.org, cgroups@vger.kernel.org Message-ID: <57D9DBC9.2010605@digikod.net> Subject: Re: [RFC v3 03/22] bpf,landlock: Add a new arraymap type to deal with (Landlock) handles References: <20160914072415.26021-1-mic@digikod.net> <20160914072415.26021-4-mic@digikod.net> <20160914185157.GA53542@ast-mbp.thefacebook.com> In-Reply-To: <20160914185157.GA53542@ast-mbp.thefacebook.com> --kGu4VJSvr7M189NUoiXHrVNXfHAD1iXGI Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 14/09/2016 20:51, Alexei Starovoitov wrote: > On Wed, Sep 14, 2016 at 09:23:56AM +0200, Micka=EBl Sala=FCn wrote: >> This new arraymap looks like a set and brings new properties: >> * strong typing of entries: the eBPF functions get the array type of >> elements instead of CONST_PTR_TO_MAP (e.g. >> CONST_PTR_TO_LANDLOCK_HANDLE_FS); >> * force sequential filling (i.e. replace or append-only update), which= >> allow quick browsing of all entries. >> >> This strong typing is useful to statically check if the content of a m= ap >> can be passed to an eBPF function. For example, Landlock use it to sto= re >> and manage kernel objects (e.g. struct file) instead of dealing with >> userland raw data. This improve efficiency and ensure that an eBPF >> program can only call functions with the right high-level arguments. >> >> The enum bpf_map_handle_type list low-level types (e.g. >> BPF_MAP_HANDLE_TYPE_LANDLOCK_FS_FD) which are identified when >> updating a map entry (handle). This handle types are used to infer a >> high-level arraymap type which are listed in enum bpf_map_array_type >> (e.g. BPF_MAP_ARRAY_TYPE_LANDLOCK_FS). >> >> For now, this new arraymap is only used by Landlock LSM (cf. next >> commits) but it could be useful for other needs. >> >> Changes since v2: >> * add a RLIMIT_NOFILE-based limit to the maximum number of arraymap >> handle entries (suggested by Andy Lutomirski) >> * remove useless checks >> >> Changes since v1: >> * arraymap of handles replace custom checker groups >> * simpler userland API >> >> Signed-off-by: Micka=EBl Sala=FCn >> Cc: Alexei Starovoitov >> Cc: Andy Lutomirski >> Cc: Daniel Borkmann >> Cc: David S. Miller >> Cc: Kees Cook >> Link: https://lkml.kernel.org/r/CALCETrWwTiz3kZTkEgOW24-DvhQq6LftwEXh7= 7FD2G5o71yD7g@mail.gmail.com >> --- >> include/linux/bpf.h | 14 ++++ >> include/uapi/linux/bpf.h | 18 +++++ >> kernel/bpf/arraymap.c | 203 ++++++++++++++++++++++++++++++++++++++= +++++++++ >> kernel/bpf/verifier.c | 12 ++- >> 4 files changed, 246 insertions(+), 1 deletion(-) >> >> diff --git a/include/linux/bpf.h b/include/linux/bpf.h >> index fa9a988400d9..eae4ce4542c1 100644 >> --- a/include/linux/bpf.h >> +++ b/include/linux/bpf.h >> @@ -13,6 +13,10 @@ >> #include >> #include >> =20 >> +#ifdef CONFIG_SECURITY_LANDLOCK >> +#include /* struct file */ >> +#endif /* CONFIG_SECURITY_LANDLOCK */ >> + >> struct perf_event; >> struct bpf_map; >> =20 >> @@ -38,6 +42,7 @@ struct bpf_map_ops { >> struct bpf_map { >> atomic_t refcnt; >> enum bpf_map_type map_type; >> + enum bpf_map_array_type map_array_type; >> u32 key_size; >> u32 value_size; >> u32 max_entries; >> @@ -187,6 +192,9 @@ struct bpf_array { >> */ >> enum bpf_prog_type owner_prog_type; >> bool owner_jited; >> +#ifdef CONFIG_SECURITY_LANDLOCK >> + u32 n_entries; /* number of entries in a handle array */ >> +#endif /* CONFIG_SECURITY_LANDLOCK */ >> union { >> char value[0] __aligned(8); >> void *ptrs[0] __aligned(8); >> @@ -194,6 +202,12 @@ struct bpf_array { >> }; >> }; >> =20 >> +#ifdef CONFIG_SECURITY_LANDLOCK >> +struct map_landlock_handle { >> + u32 type; /* enum bpf_map_handle_type */ >> +}; >> +#endif /* CONFIG_SECURITY_LANDLOCK */ >> + >> #define MAX_TAIL_CALL_CNT 32 >> =20 >> struct bpf_event_entry { >> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h >> index 7cd36166f9b7..b68de57f7ab8 100644 >> --- a/include/uapi/linux/bpf.h >> +++ b/include/uapi/linux/bpf.h >> @@ -87,6 +87,15 @@ enum bpf_map_type { >> BPF_MAP_TYPE_PERCPU_ARRAY, >> BPF_MAP_TYPE_STACK_TRACE,P_TYPE_CGROUP_ARRAY >> BPF_MAP_TYPE_CGROUP_ARRAY, >> + BPF_MAP_TYPE_LANDLOCK_ARRAY, >> +}; >> + >> +enum bpf_map_array_type { >> + BPF_MAP_ARRAY_TYPE_UNSPEC, >> +}; >> + >> +enum bpf_map_handle_type { >> + BPF_MAP_HANDLE_TYPE_UNSPEC, >> }; >=20 > missing something. why it has to be special to have it's own > fd array implementation? > Please take a look how BPF_MAP_TYPE_PERF_EVENT_ARRAY,=20 > BPF_MAP_TYPE_CGROUP_ARRAY and BPF_MAP_TYPE_PROG_ARRAY are done. > The all store objects into array map that user space passes via FD. > I think the same model should apply here. The idea is to have multiple way for userland to describe a resource (e.g. an open file descriptor, a path or a glob pattern). The kernel representation could then be a "struct path *" or dedicated types (e.g. custom glob). Another interesting point (that could replace check_map_func_compatibility()) is that BPF_MAP_TYPE_LANDLOCK_ARRAY translate to dedicated (abstract) types (instead of CONST_PTR_TO_MAP) thanks to bpf_reg_type_from_map(). This is useful to abstract userland (map) interface with kernel object(s) dealing with that type. A third point is that BPF_MAP_TYPE_LANDLOCK_ARRAY is a kind of set. It is optimized to quickly walk through all the elements in a sequential way= =2E --kGu4VJSvr7M189NUoiXHrVNXfHAD1iXGI-- --UPGkAw2AHu1mFktC0wkiPFcXM1xMapqCd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJX2dvJAAoJECLe/t9zvWqVMtIIAKWa0Kw454QRJ8SX7w4o06TU By7mOwkMUS5UAbOdwikhxTq/+DU6xZh7E1MU00dBnDjxPxVDbcpZOmbEpLq+ypkg 2ZK7JmNDOL08HuZRUqIY760ScQoxqE1s82Qyh9XqhTL2Dms7SU2VvUBA7clWlhiL dXri+gau+++un4d33v9I+d91lEsoOHnYrjKzHch7MDkWzJSRAfkGBk22Uko4iBNc R7lWq/oEPQEnsKjYxDjZhLRz46hSiGXDwL/iHe6aZaWHkzMbFqU7MgYZfRmqeAEZ ifHRFdnTZl3T+SmbBTitylbhUYjQBjLXj+en6RcpvzRJ+INikD39BSIaKLHhdP8= =F9R/ -----END PGP SIGNATURE----- --UPGkAw2AHu1mFktC0wkiPFcXM1xMapqCd-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= Subject: Re: [RFC v3 03/22] bpf,landlock: Add a new arraymap type to deal with (Landlock) handles Date: Thu, 15 Sep 2016 01:22:49 +0200 Message-ID: <57D9DBC9.2010605@digikod.net> References: <20160914072415.26021-1-mic@digikod.net> <20160914072415.26021-4-mic@digikod.net> <20160914185157.GA53542@ast-mbp.thefacebook.com> Reply-To: kernel-hardening@lists.openwall.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UPGkAw2AHu1mFktC0wkiPFcXM1xMapqCd" Cc: linux-kernel@vger.kernel.org, Alexei Starovoitov , Andy Lutomirski , Arnd Bergmann , Casey Schaufler , Daniel Borkmann , Daniel Mack , David Drysdale , "David S . Miller" , Elena Reshetova , "Eric W . Biederman" , James Morris , Kees Cook , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Tejun Heo , Will Drewry , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-security-module@vger.kernel.org, netdev@vger.ker To: Alexei Starovoitov Return-path: List-Post: List-Help: List-Unsubscribe: List-Subscribe: In-Reply-To: <20160914185157.GA53542@ast-mbp.thefacebook.com> List-Id: netdev.vger.kernel.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UPGkAw2AHu1mFktC0wkiPFcXM1xMapqCd Content-Type: multipart/mixed; boundary="kGu4VJSvr7M189NUoiXHrVNXfHAD1iXGI"; protected-headers="v1" From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= To: Alexei Starovoitov Cc: linux-kernel@vger.kernel.org, Alexei Starovoitov , Andy Lutomirski , Arnd Bergmann , Casey Schaufler , Daniel Borkmann , Daniel Mack , David Drysdale , "David S . Miller" , Elena Reshetova , "Eric W . Biederman" , James Morris , Kees Cook , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Tejun Heo , Will Drewry , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-security-module@vger.kernel.org, netdev@vger.kernel.org, cgroups@vger.kernel.org Message-ID: <57D9DBC9.2010605@digikod.net> Subject: Re: [RFC v3 03/22] bpf,landlock: Add a new arraymap type to deal with (Landlock) handles References: <20160914072415.26021-1-mic@digikod.net> <20160914072415.26021-4-mic@digikod.net> <20160914185157.GA53542@ast-mbp.thefacebook.com> In-Reply-To: <20160914185157.GA53542@ast-mbp.thefacebook.com> --kGu4VJSvr7M189NUoiXHrVNXfHAD1iXGI Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 14/09/2016 20:51, Alexei Starovoitov wrote: > On Wed, Sep 14, 2016 at 09:23:56AM +0200, Micka=EBl Sala=FCn wrote: >> This new arraymap looks like a set and brings new properties: >> * strong typing of entries: the eBPF functions get the array type of >> elements instead of CONST_PTR_TO_MAP (e.g. >> CONST_PTR_TO_LANDLOCK_HANDLE_FS); >> * force sequential filling (i.e. replace or append-only update), which= >> allow quick browsing of all entries. >> >> This strong typing is useful to statically check if the content of a m= ap >> can be passed to an eBPF function. For example, Landlock use it to sto= re >> and manage kernel objects (e.g. struct file) instead of dealing with >> userland raw data. This improve efficiency and ensure that an eBPF >> program can only call functions with the right high-level arguments. >> >> The enum bpf_map_handle_type list low-level types (e.g. >> BPF_MAP_HANDLE_TYPE_LANDLOCK_FS_FD) which are identified when >> updating a map entry (handle). This handle types are used to infer a >> high-level arraymap type which are listed in enum bpf_map_array_type >> (e.g. BPF_MAP_ARRAY_TYPE_LANDLOCK_FS). >> >> For now, this new arraymap is only used by Landlock LSM (cf. next >> commits) but it could be useful for other needs. >> >> Changes since v2: >> * add a RLIMIT_NOFILE-based limit to the maximum number of arraymap >> handle entries (suggested by Andy Lutomirski) >> * remove useless checks >> >> Changes since v1: >> * arraymap of handles replace custom checker groups >> * simpler userland API >> >> Signed-off-by: Micka=EBl Sala=FCn >> Cc: Alexei Starovoitov >> Cc: Andy Lutomirski >> Cc: Daniel Borkmann >> Cc: David S. Miller >> Cc: Kees Cook >> Link: https://lkml.kernel.org/r/CALCETrWwTiz3kZTkEgOW24-DvhQq6LftwEXh7= 7FD2G5o71yD7g@mail.gmail.com >> --- >> include/linux/bpf.h | 14 ++++ >> include/uapi/linux/bpf.h | 18 +++++ >> kernel/bpf/arraymap.c | 203 ++++++++++++++++++++++++++++++++++++++= +++++++++ >> kernel/bpf/verifier.c | 12 ++- >> 4 files changed, 246 insertions(+), 1 deletion(-) >> >> diff --git a/include/linux/bpf.h b/include/linux/bpf.h >> index fa9a988400d9..eae4ce4542c1 100644 >> --- a/include/linux/bpf.h >> +++ b/include/linux/bpf.h >> @@ -13,6 +13,10 @@ >> #include >> #include >> =20 >> +#ifdef CONFIG_SECURITY_LANDLOCK >> +#include /* struct file */ >> +#endif /* CONFIG_SECURITY_LANDLOCK */ >> + >> struct perf_event; >> struct bpf_map; >> =20 >> @@ -38,6 +42,7 @@ struct bpf_map_ops { >> struct bpf_map { >> atomic_t refcnt; >> enum bpf_map_type map_type; >> + enum bpf_map_array_type map_array_type; >> u32 key_size; >> u32 value_size; >> u32 max_entries; >> @@ -187,6 +192,9 @@ struct bpf_array { >> */ >> enum bpf_prog_type owner_prog_type; >> bool owner_jited; >> +#ifdef CONFIG_SECURITY_LANDLOCK >> + u32 n_entries; /* number of entries in a handle array */ >> +#endif /* CONFIG_SECURITY_LANDLOCK */ >> union { >> char value[0] __aligned(8); >> void *ptrs[0] __aligned(8); >> @@ -194,6 +202,12 @@ struct bpf_array { >> }; >> }; >> =20 >> +#ifdef CONFIG_SECURITY_LANDLOCK >> +struct map_landlock_handle { >> + u32 type; /* enum bpf_map_handle_type */ >> +}; >> +#endif /* CONFIG_SECURITY_LANDLOCK */ >> + >> #define MAX_TAIL_CALL_CNT 32 >> =20 >> struct bpf_event_entry { >> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h >> index 7cd36166f9b7..b68de57f7ab8 100644 >> --- a/include/uapi/linux/bpf.h >> +++ b/include/uapi/linux/bpf.h >> @@ -87,6 +87,15 @@ enum bpf_map_type { >> BPF_MAP_TYPE_PERCPU_ARRAY, >> BPF_MAP_TYPE_STACK_TRACE,P_TYPE_CGROUP_ARRAY >> BPF_MAP_TYPE_CGROUP_ARRAY, >> + BPF_MAP_TYPE_LANDLOCK_ARRAY, >> +}; >> + >> +enum bpf_map_array_type { >> + BPF_MAP_ARRAY_TYPE_UNSPEC, >> +}; >> + >> +enum bpf_map_handle_type { >> + BPF_MAP_HANDLE_TYPE_UNSPEC, >> }; >=20 > missing something. why it has to be special to have it's own > fd array implementation? > Please take a look how BPF_MAP_TYPE_PERF_EVENT_ARRAY,=20 > BPF_MAP_TYPE_CGROUP_ARRAY and BPF_MAP_TYPE_PROG_ARRAY are done. > The all store objects into array map that user space passes via FD. > I think the same model should apply here. The idea is to have multiple way for userland to describe a resource (e.g. an open file descriptor, a path or a glob pattern). The kernel representation could then be a "struct path *" or dedicated types (e.g. custom glob). Another interesting point (that could replace check_map_func_compatibility()) is that BPF_MAP_TYPE_LANDLOCK_ARRAY translate to dedicated (abstract) types (instead of CONST_PTR_TO_MAP) thanks to bpf_reg_type_from_map(). This is useful to abstract userland (map) interface with kernel object(s) dealing with that type. A third point is that BPF_MAP_TYPE_LANDLOCK_ARRAY is a kind of set. It is optimized to quickly walk through all the elements in a sequential way= =2E --kGu4VJSvr7M189NUoiXHrVNXfHAD1iXGI-- --UPGkAw2AHu1mFktC0wkiPFcXM1xMapqCd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJX2dvJAAoJECLe/t9zvWqVMtIIAKWa0Kw454QRJ8SX7w4o06TU By7mOwkMUS5UAbOdwikhxTq/+DU6xZh7E1MU00dBnDjxPxVDbcpZOmbEpLq+ypkg 2ZK7JmNDOL08HuZRUqIY760ScQoxqE1s82Qyh9XqhTL2Dms7SU2VvUBA7clWlhiL dXri+gau+++un4d33v9I+d91lEsoOHnYrjKzHch7MDkWzJSRAfkGBk22Uko4iBNc R7lWq/oEPQEnsKjYxDjZhLRz46hSiGXDwL/iHe6aZaWHkzMbFqU7MgYZfRmqeAEZ ifHRFdnTZl3T+SmbBTitylbhUYjQBjLXj+en6RcpvzRJ+INikD39BSIaKLHhdP8= =F9R/ -----END PGP SIGNATURE----- --UPGkAw2AHu1mFktC0wkiPFcXM1xMapqCd-- From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com References: <20160914072415.26021-1-mic@digikod.net> <20160914072415.26021-4-mic@digikod.net> <20160914185157.GA53542@ast-mbp.thefacebook.com> From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= Message-ID: <57D9DBC9.2010605@digikod.net> Date: Thu, 15 Sep 2016 01:22:49 +0200 MIME-Version: 1.0 In-Reply-To: <20160914185157.GA53542@ast-mbp.thefacebook.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UPGkAw2AHu1mFktC0wkiPFcXM1xMapqCd" Subject: [kernel-hardening] Re: [RFC v3 03/22] bpf,landlock: Add a new arraymap type to deal with (Landlock) handles To: Alexei Starovoitov Cc: linux-kernel@vger.kernel.org, Alexei Starovoitov , Andy Lutomirski , Arnd Bergmann , Casey Schaufler , Daniel Borkmann , Daniel Mack , David Drysdale , "David S . Miller" , Elena Reshetova , "Eric W . Biederman" , James Morris , Kees Cook , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Tejun Heo , Will Drewry , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-security-module@vger.kernel.org, netdev@vger.kernel.org, cgroups@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UPGkAw2AHu1mFktC0wkiPFcXM1xMapqCd Content-Type: multipart/mixed; boundary="kGu4VJSvr7M189NUoiXHrVNXfHAD1iXGI"; protected-headers="v1" From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= To: Alexei Starovoitov Cc: linux-kernel@vger.kernel.org, Alexei Starovoitov , Andy Lutomirski , Arnd Bergmann , Casey Schaufler , Daniel Borkmann , Daniel Mack , David Drysdale , "David S . Miller" , Elena Reshetova , "Eric W . Biederman" , James Morris , Kees Cook , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Tejun Heo , Will Drewry , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-security-module@vger.kernel.org, netdev@vger.kernel.org, cgroups@vger.kernel.org Message-ID: <57D9DBC9.2010605@digikod.net> Subject: Re: [RFC v3 03/22] bpf,landlock: Add a new arraymap type to deal with (Landlock) handles References: <20160914072415.26021-1-mic@digikod.net> <20160914072415.26021-4-mic@digikod.net> <20160914185157.GA53542@ast-mbp.thefacebook.com> In-Reply-To: <20160914185157.GA53542@ast-mbp.thefacebook.com> --kGu4VJSvr7M189NUoiXHrVNXfHAD1iXGI Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 14/09/2016 20:51, Alexei Starovoitov wrote: > On Wed, Sep 14, 2016 at 09:23:56AM +0200, Micka=EBl Sala=FCn wrote: >> This new arraymap looks like a set and brings new properties: >> * strong typing of entries: the eBPF functions get the array type of >> elements instead of CONST_PTR_TO_MAP (e.g. >> CONST_PTR_TO_LANDLOCK_HANDLE_FS); >> * force sequential filling (i.e. replace or append-only update), which= >> allow quick browsing of all entries. >> >> This strong typing is useful to statically check if the content of a m= ap >> can be passed to an eBPF function. For example, Landlock use it to sto= re >> and manage kernel objects (e.g. struct file) instead of dealing with >> userland raw data. This improve efficiency and ensure that an eBPF >> program can only call functions with the right high-level arguments. >> >> The enum bpf_map_handle_type list low-level types (e.g. >> BPF_MAP_HANDLE_TYPE_LANDLOCK_FS_FD) which are identified when >> updating a map entry (handle). This handle types are used to infer a >> high-level arraymap type which are listed in enum bpf_map_array_type >> (e.g. BPF_MAP_ARRAY_TYPE_LANDLOCK_FS). >> >> For now, this new arraymap is only used by Landlock LSM (cf. next >> commits) but it could be useful for other needs. >> >> Changes since v2: >> * add a RLIMIT_NOFILE-based limit to the maximum number of arraymap >> handle entries (suggested by Andy Lutomirski) >> * remove useless checks >> >> Changes since v1: >> * arraymap of handles replace custom checker groups >> * simpler userland API >> >> Signed-off-by: Micka=EBl Sala=FCn >> Cc: Alexei Starovoitov >> Cc: Andy Lutomirski >> Cc: Daniel Borkmann >> Cc: David S. Miller >> Cc: Kees Cook >> Link: https://lkml.kernel.org/r/CALCETrWwTiz3kZTkEgOW24-DvhQq6LftwEXh7= 7FD2G5o71yD7g@mail.gmail.com >> --- >> include/linux/bpf.h | 14 ++++ >> include/uapi/linux/bpf.h | 18 +++++ >> kernel/bpf/arraymap.c | 203 ++++++++++++++++++++++++++++++++++++++= +++++++++ >> kernel/bpf/verifier.c | 12 ++- >> 4 files changed, 246 insertions(+), 1 deletion(-) >> >> diff --git a/include/linux/bpf.h b/include/linux/bpf.h >> index fa9a988400d9..eae4ce4542c1 100644 >> --- a/include/linux/bpf.h >> +++ b/include/linux/bpf.h >> @@ -13,6 +13,10 @@ >> #include >> #include >> =20 >> +#ifdef CONFIG_SECURITY_LANDLOCK >> +#include /* struct file */ >> +#endif /* CONFIG_SECURITY_LANDLOCK */ >> + >> struct perf_event; >> struct bpf_map; >> =20 >> @@ -38,6 +42,7 @@ struct bpf_map_ops { >> struct bpf_map { >> atomic_t refcnt; >> enum bpf_map_type map_type; >> + enum bpf_map_array_type map_array_type; >> u32 key_size; >> u32 value_size; >> u32 max_entries; >> @@ -187,6 +192,9 @@ struct bpf_array { >> */ >> enum bpf_prog_type owner_prog_type; >> bool owner_jited; >> +#ifdef CONFIG_SECURITY_LANDLOCK >> + u32 n_entries; /* number of entries in a handle array */ >> +#endif /* CONFIG_SECURITY_LANDLOCK */ >> union { >> char value[0] __aligned(8); >> void *ptrs[0] __aligned(8); >> @@ -194,6 +202,12 @@ struct bpf_array { >> }; >> }; >> =20 >> +#ifdef CONFIG_SECURITY_LANDLOCK >> +struct map_landlock_handle { >> + u32 type; /* enum bpf_map_handle_type */ >> +}; >> +#endif /* CONFIG_SECURITY_LANDLOCK */ >> + >> #define MAX_TAIL_CALL_CNT 32 >> =20 >> struct bpf_event_entry { >> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h >> index 7cd36166f9b7..b68de57f7ab8 100644 >> --- a/include/uapi/linux/bpf.h >> +++ b/include/uapi/linux/bpf.h >> @@ -87,6 +87,15 @@ enum bpf_map_type { >> BPF_MAP_TYPE_PERCPU_ARRAY, >> BPF_MAP_TYPE_STACK_TRACE,P_TYPE_CGROUP_ARRAY >> BPF_MAP_TYPE_CGROUP_ARRAY, >> + BPF_MAP_TYPE_LANDLOCK_ARRAY, >> +}; >> + >> +enum bpf_map_array_type { >> + BPF_MAP_ARRAY_TYPE_UNSPEC, >> +}; >> + >> +enum bpf_map_handle_type { >> + BPF_MAP_HANDLE_TYPE_UNSPEC, >> }; >=20 > missing something. why it has to be special to have it's own > fd array implementation? > Please take a look how BPF_MAP_TYPE_PERF_EVENT_ARRAY,=20 > BPF_MAP_TYPE_CGROUP_ARRAY and BPF_MAP_TYPE_PROG_ARRAY are done. > The all store objects into array map that user space passes via FD. > I think the same model should apply here. The idea is to have multiple way for userland to describe a resource (e.g. an open file descriptor, a path or a glob pattern). The kernel representation could then be a "struct path *" or dedicated types (e.g. custom glob). Another interesting point (that could replace check_map_func_compatibility()) is that BPF_MAP_TYPE_LANDLOCK_ARRAY translate to dedicated (abstract) types (instead of CONST_PTR_TO_MAP) thanks to bpf_reg_type_from_map(). This is useful to abstract userland (map) interface with kernel object(s) dealing with that type. A third point is that BPF_MAP_TYPE_LANDLOCK_ARRAY is a kind of set. It is optimized to quickly walk through all the elements in a sequential way= =2E --kGu4VJSvr7M189NUoiXHrVNXfHAD1iXGI-- --UPGkAw2AHu1mFktC0wkiPFcXM1xMapqCd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJX2dvJAAoJECLe/t9zvWqVMtIIAKWa0Kw454QRJ8SX7w4o06TU By7mOwkMUS5UAbOdwikhxTq/+DU6xZh7E1MU00dBnDjxPxVDbcpZOmbEpLq+ypkg 2ZK7JmNDOL08HuZRUqIY760ScQoxqE1s82Qyh9XqhTL2Dms7SU2VvUBA7clWlhiL dXri+gau+++un4d33v9I+d91lEsoOHnYrjKzHch7MDkWzJSRAfkGBk22Uko4iBNc R7lWq/oEPQEnsKjYxDjZhLRz46hSiGXDwL/iHe6aZaWHkzMbFqU7MgYZfRmqeAEZ ifHRFdnTZl3T+SmbBTitylbhUYjQBjLXj+en6RcpvzRJ+INikD39BSIaKLHhdP8= =F9R/ -----END PGP SIGNATURE----- --UPGkAw2AHu1mFktC0wkiPFcXM1xMapqCd--