| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <607ceb21-5aa5-678b-4438-0d8dcb69fc3c@digikod.net>
Date: Wed, 23 Aug 2017 09:45:24 +0200
From: Mickaël Salaün <mic@...ikod.net>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: linux-kernel@...r.kernel.org, Alexei Starovoitov <ast@...nel.org>,
Andy Lutomirski <luto@...capital.net>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Casey Schaufler <casey@...aufler-ca.com>,
Daniel Borkmann <daniel@...earbox.net>,
David Drysdale <drysdale@...gle.com>,
"David S . Miller" <davem@...emloft.net>,
"Eric W . Biederman" <ebiederm@...ssion.com>,
James Morris <james.l.morris@...cle.com>,
Jann Horn <jann@...jh.net>, Jonathan Corbet <corbet@....net>,
Matthew Garrett <mjg59@...f.ucam.org>,
Michael Kerrisk <mtk.manpages@...il.com>,
Kees Cook <keescook@...omium.org>,
Paul Moore <paul@...l-moore.com>,
Sargun Dhillon <sargun@...gun.me>,
"Serge E . Hallyn" <serge@...lyn.com>,
Shuah Khan <shuah@...nel.org>, 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
Subject: Re: [PATCH net-next v7 02/10] bpf: Add eBPF program subtype and
is_valid_subtype() verifier
On 23/08/2017 04:44, Alexei Starovoitov wrote:
> On Mon, Aug 21, 2017 at 02:09:25AM +0200, Mickaël Salaün wrote:
>> The goal of the program subtype is to be able to have different static
>> fine-grained verifications for a unique program type.
>>
>> The struct bpf_verifier_ops gets a new optional function:
>> is_valid_subtype(). This new verifier is called at the beginning of the
>> eBPF program verification to check if the (optional) program subtype is
>> valid.
>>
>> For now, only Landlock eBPF programs are using a program subtype (see
>> next commit) but this could be used by other program types in the future.
>>
>> Signed-off-by: Mickaël Salaün <mic@...ikod.net>
>> Cc: Alexei Starovoitov <ast@...nel.org>
>> Cc: Arnaldo Carvalho de Melo <acme@...nel.org>
>> Cc: Daniel Borkmann <daniel@...earbox.net>
>> Cc: David S. Miller <davem@...emloft.net>
>> Link: https://lkml.kernel.org/r/20160827205559.GA43880@ast-mbp.thefacebook.com
>> ---
>>
>> Changes since v6:
>> * rename Landlock version to ABI to better reflect its purpose
>> * fix unsigned integer checks
>> * fix pointer cast
>> * constify pointers
>> * rebase
>>
>> Changes since v5:
>> * use a prog_subtype pointer and make it future-proof
>> * add subtype test
>> * constify bpf_load_program()'s subtype argument
>> * cleanup subtype initialization
>> * rebase
>>
>> Changes since v4:
>> * replace the "status" field with "version" (more generic)
>> * replace the "access" field with "ability" (less confusing)
>>
>> Changes since v3:
>> * remove the "origin" field
>> * add an "option" field
>> * cleanup comments
>> ---
>> include/linux/bpf.h | 7 ++-
>> include/linux/filter.h | 2 +
>> include/uapi/linux/bpf.h | 11 +++++
>> kernel/bpf/syscall.c | 22 ++++++++-
>> kernel/bpf/verifier.c | 17 +++++--
>> kernel/trace/bpf_trace.c | 15 ++++--
>> net/core/filter.c | 71 ++++++++++++++++++-----------
>> samples/bpf/bpf_load.c | 3 +-
>> samples/bpf/cookie_uid_helper_example.c | 2 +-
>> samples/bpf/fds_example.c | 2 +-
>> samples/bpf/sock_example.c | 3 +-
>> samples/bpf/test_cgrp2_attach.c | 2 +-
>> samples/bpf/test_cgrp2_attach2.c | 2 +-
>> samples/bpf/test_cgrp2_sock.c | 2 +-
>> tools/include/uapi/linux/bpf.h | 11 +++++
>> tools/lib/bpf/bpf.c | 10 +++-
>> tools/lib/bpf/bpf.h | 5 +-
>> tools/lib/bpf/libbpf.c | 4 +-
>> tools/perf/tests/bpf.c | 2 +-
>> tools/testing/selftests/bpf/test_align.c | 2 +-
>> tools/testing/selftests/bpf/test_tag.c | 2 +-
>> tools/testing/selftests/bpf/test_verifier.c | 17 ++++++-
>> 22 files changed, 158 insertions(+), 56 deletions(-)
>
> ...
>
>> diff --git a/include/linux/filter.h b/include/linux/filter.h
>> index 7015116331af..0c3fadbb5a58 100644
>> --- a/include/linux/filter.h
>> +++ b/include/linux/filter.h
>> @@ -464,6 +464,8 @@ struct bpf_prog {
>> u32 len; /* Number of filter blocks */
>> u32 jited_len; /* Size of jited insns in bytes */
>> u8 tag[BPF_TAG_SIZE];
>> + u8 has_subtype;
>> + union bpf_prog_subtype subtype; /* Fine-grained verifications */
>
> these burn a hole in very performance sensitive structure.
> Also there are bits rigth above. use them instead of u8 has_subtype?
> or can these two fields be part of bpf_prog_aux ?
OK, I'll create one bit variable and a bpf_prog_subtype field in the
bpf_prog_aux struct then.
>
>> struct bpf_prog_aux *aux; /* Auxiliary fields */
>> struct sock_fprog_kern *orig_prog; /* Original BPF program */
>> unsigned int (*bpf_func)(const void *ctx,
>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
>> index 843818dff96d..8541ab85e432 100644
>> --- a/include/uapi/linux/bpf.h
>> +++ b/include/uapi/linux/bpf.h
>> @@ -177,6 +177,15 @@ enum bpf_attach_type {
>> /* Specify numa node during map creation */
>> #define BPF_F_NUMA_NODE (1U << 2)
>>
>> +union bpf_prog_subtype {
>> + 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.
>
>> + __u32 event; /* enum landlock_subtype_event */
>> + __aligned_u64 ability; /* LANDLOCK_SUBTYPE_ABILITY_* */
>> + __aligned_u64 option; /* LANDLOCK_SUBTYPE_OPTION_* */
>> + } landlock_rule;
>> +} __attribute__((aligned(8)));
>> +
>> union bpf_attr {
>> struct { /* anonymous struct used by BPF_MAP_CREATE command */
>> __u32 map_type; /* one of enum bpf_map_type */
>> @@ -212,6 +221,8 @@ union bpf_attr {
>> __aligned_u64 log_buf; /* user supplied buffer */
>> __u32 kern_version; /* checked when prog_type=kprobe */
>> __u32 prog_flags;
>> + __aligned_u64 prog_subtype; /* bpf_prog_subtype address */
>> + __u32 prog_subtype_size;
>> };
>
> more general question: what is the status of security/ bits?
> I'm assuming they still need to be reviewed and explicitly acked by James, right?
Right, the review process is ongoing. :)
BTW, I'll be at Linux Security Summit (co-located with Plumbers) next
month. We'll be able to clarify some points there too.
Regards,
Mickaël
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists