[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 26 Oct 2016 21:01:47 +0200
From: Jann Horn <jann@...jh.net>
To: Mickaël Salaün <mic@...ikod.net>
Cc: linux-kernel@...r.kernel.org, Alexei Starovoitov <ast@...nel.org>,
Andy Lutomirski <luto@...capital.net>,
Daniel Borkmann <daniel@...earbox.net>,
Daniel Mack <daniel@...que.org>,
David Drysdale <drysdale@...gle.com>,
"David S . Miller" <davem@...emloft.net>,
"Eric W . Biederman" <ebiederm@...ssion.com>,
James Morris <james.l.morris@...cle.com>,
Kees Cook <keescook@...omium.org>, Paul Moore <pmoore@...hat.com>,
Sargun Dhillon <sargun@...gun.me>,
"Serge E . Hallyn" <serge@...lyn.com>, Tejun Heo <tj@...nel.org>,
Thomas Graf <tgraf@...g.ch>, Will Drewry <wad@...omium.org>,
kernel-hardening@...ts.openwall.com, linux-api@...r.kernel.org,
linux-security-module@...r.kernel.org, netdev@...r.kernel.org,
cgroups@...r.kernel.org
Subject: Re: [RFC v4 03/18] bpf,landlock: Add a new
arraymap type to deal with (Landlock) handles
On Wed, Oct 26, 2016 at 08:56:39AM +0200, Mickaël Salaün 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 map
> can be passed to an eBPF function. For example, Landlock use it to store
> 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 v3:
> * make handle arraymap safe (RCU) and remove buggy synchronize_rcu()
> * factor out the arraymay walk
>
> 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
[...]
> + case BPF_MAP_HANDLE_TYPE_LANDLOCK_FS_FD:
> + handle_file = fget(handle->fd);
> + if (IS_ERR(handle_file))
> + return ERR_CAST(handle_file);
> + /* check if the FD is tied to a user mount point */
> + if (unlikely(handle_file->f_path.mnt->mnt_flags & MNT_INTERNAL)) {
> + fput(handle_file);
> + return ERR_PTR(-EINVAL);
> + }
> + path_get(&handle_file->f_path);
> + ret = kmalloc(sizeof(*ret), GFP_KERNEL);
> + ret->path = handle_file->f_path;
> + fput(handle_file);
You can use fdget() and fdput() here because the reference to
handle_file is dropped before the end of the syscall.
> + break;
> + case BPF_MAP_HANDLE_TYPE_UNSPEC:
> + default:
> + return ERR_PTR(-EINVAL);
> + }
> + ret->type = handle_type;
> + return ret;
> +}
> +
> +static void *nop_map_lookup_elem(struct bpf_map *map, void *key)
> +{
> + return ERR_PTR(-EINVAL);
> +}
> +
> +/* called from syscall or from eBPF program */
> +static int landlock_array_map_update_elem(struct bpf_map *map, void *key,
> + void *value, u64 map_flags)
> +{
This being callable from eBPF context is IMO pretty surprising and should
at least be well-documented. Also: What is the usecase here?
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
