netdev - Re: [PATCH bpf-next v5 1/2] bpf: extend stackmap to save binary_build

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <28899DE0-439F-4725-B29E-478E1B1A00C1@fb.com>
Date:   Wed, 14 Mar 2018 16:36:53 +0000
From:   Song Liu <songliubraving@...com>
To:     Daniel Borkmann <daniel@...earbox.net>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "ast@...nel.org" <ast@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Kernel Team <Kernel-team@...com>,
        "hannes@...xchg.org" <hannes@...xchg.org>,
        Teng Qin <qinteng@...com>
Subject: Re: [PATCH bpf-next v5 1/2] bpf: extend stackmap to save
 binary_build_id+offset instead of address



> On Mar 14, 2018, at 9:07 AM, Daniel Borkmann <daniel@...earbox.net> wrote:
> 
> Just a minor question below, the rest seems fine to me as far as I
> can tell.
> 
> On 03/13/2018 10:47 PM, Song Liu wrote:
> [...]
>> +enum bpf_stack_build_id_status {
>> +	/* user space need an empty entry to identify end of a trace */
>> +	BPF_STACK_BUILD_ID_EMPTY = 0,
>> +	/* with valid build_id and offset */
>> +	BPF_STACK_BUILD_ID_VALID = 1,
>> +	/* couldn't get build_id, fallback to ip */
>> +	BPF_STACK_BUILD_ID_IP = 2,
>> +};
>> +
>> +#define BPF_BUILD_ID_SIZE 20
>> +struct bpf_stack_build_id {
>> +	__s32		status;
>> +	unsigned char	build_id[BPF_BUILD_ID_SIZE];
>> +	union {
>> +		__u64	offset;
>> +		__u64	ip;
>> +	};
>> +};
> [...]>  BPF_CALL_3(bpf_get_stackid, struct pt_regs *, regs, struct bpf_map *, map,
>> 	   u64, flags)
>> {
>> 	struct bpf_stack_map *smap = container_of(map, struct bpf_stack_map, map);
>> 	struct perf_callchain_entry *trace;
>> 	struct stack_map_bucket *bucket, *new_bucket, *old_bucket;
>> -	u32 max_depth = map->value_size / 8;
>> +	u32 max_depth = map->value_size / stack_map_data_size(map);
>> 	/* stack_map_alloc() checks that max_depth <= sysctl_perf_event_max_stack */
>> 	u32 init_nr = sysctl_perf_event_max_stack - max_depth;
>> 	u32 skip = flags & BPF_F_SKIP_FIELD_MASK;
>> @@ -128,11 +318,16 @@ BPF_CALL_3(bpf_get_stackid, struct pt_regs *, regs, struct bpf_map *, map,
>> 	bool user = flags & BPF_F_USER_STACK;
>> 	bool kernel = !user;
>> 	u64 *ips;
>> +	bool hash_matches;
>> 
>> 	if (unlikely(flags & ~(BPF_F_SKIP_FIELD_MASK | BPF_F_USER_STACK |
>> 			       BPF_F_FAST_STACK_CMP | BPF_F_REUSE_STACKID)))
>> 		return -EINVAL;
>> 
>> +	/* build_id+offset stack map only supports user stack */
>> +	if (stack_map_use_build_id(map) && !user)
>> +		return -EINVAL;
> 
> Instead of bailing out here, wouldn't it make sense to just reuse the
> BPF_STACK_BUILD_ID_IP status and use this 'fallback' for kernel similar
> to what we do anyway in stack_map_get_build_id_offset() when we cannot
> get the build id so that map can be used for both cases?

This a great idea! Let me implement it. 

Thanks,
Song